Optional Value. Уменьшение количества null reference-ов. - Архитектура программного обеспечения

Здравствуйте, Sinclair, Вы писали:

S>Не очень понятен смысл неиспользования null-ов. Проблема, я так понимаю, в том, что NRE упадёт слишком поздно?
Вот здесь развернутый комментарий:

OptionalValue как раз и служит для разделение опциональных и не опциональных переменных. Соответственно, для первых применяем такую запись, а для вторых обычную. А какой будет переменная T или IOptionalValue<T> определяет поставщик переменной. Если мы знаем, что поставщик соблюдает это правило, то для T можно не беспокоиться об NRE. Если поставщик не соблюдает это правило, то все как обычно, т.е. хреново: писать или не писать if, если писать, то, что внутри этого if-а делать и т.д. Глупость заключается в том, чтобы создавать эту хреновую ситуацию и в случае, если вы сами являетесь тем поставщиком.
http://rsdn.ru/forum/design/3954267.1.aspx
Автор: Alexander Polyakov
Дата: 11.09.10

Здравствуйте, gandjustas, Вы писали:

G>>>

G>>>class Ololo<T>: IOptionalValue<T>
G>>>{
G>>>    public TResult Process<TResult>(Func<T, TResult> existFunc, Func<TResult> notExistFunc)
G>>>    {
G>>>        return default(TResult);
G>>>    }
G>>>}
G>>>

AP>>где, что не работает?
G>При такой реализации IOptionalValue метода HasValue вернет false, а GetValue не бросит исключение.
Нет такого требования!

G>Это и есть контракт, который у тебя не энфорсится никак.
Нет там никакого "кролика"(контракта)

. Контракт только в твоей голове. Освободи свое сознание от шаблонов, навязанных твоей реализацией.

Здравствуйте, gandjustas, Вы писали:

G>Кстати, ты поставил минус на это сообщение, но не удосужился написать ответ.
G>Молча слил?

В своем посте я сделал замечание, чтобы не делали то-то и то-то, поскольку пример искусственный. Ты в своем посте сделал ровно то, что было в замечании. Ставлю минус, когда собеседник не слышит меня, и я теряю интерес к продолжению разговора.

G>Молча слил?
Минус это не “молча”.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Здравствуйте, gandjustas, Вы писали:

G>>>>

G>>>>class Ololo<T>: IOptionalValue<T>
G>>>>{
G>>>>    public TResult Process<TResult>(Func<T, TResult> existFunc, Func<TResult> notExistFunc)
G>>>>    {
G>>>>        return default(TResult);
G>>>>    }
G>>>>}
G>>>>

AP>>>где, что не работает?
G>>При такой реализации IOptionalValue метода HasValue вернет false, а GetValue не бросит исключение.
AP>Нет такого требования!

G>>Это и есть контракт, который у тебя не энфорсится никак.
AP>Нет там никакого "кролика"(контракта)

. Контракт только в твоей голове. Освободи свое сознание от шаблонов, навязанных твоей реализацией.

Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Здравствуйте, gandjustas, Вы писали:

G>>Кстати, ты поставил минус на это сообщение, но не удосужился написать ответ.
G>>Молча слил?

AP>В своем посте я сделал замечание, чтобы не делали то-то и то-то, поскольку пример искусственный. Ты в своем посте сделал ровно то, что было в замечании. Ставлю минус, когда собеседник не слышит меня, и я теряю интерес к продолжению разговора.
А я не должен делать как ты говоришь, ты привел пример кода, я привел аналогичный пример со своей реализацией Option, ты ничего не сказал, только минус поставил. Кроме того на вопрос не ответил, а вопрос кстати очень важный.

ЗЫ. Ты вообще не воспринимаешь критику, сразу начинаешь съезжать и придумывать небылицы. Например: нету контракта, необходима ковариантность итп. Уже не первый раз так. Не можешь адекватно вести разговор — лучше не пиши сюда.

Здравствуйте, Alexander Polyakov, Вы писали:

S>>Не очень понятен смысл неиспользования null-ов. Проблема, я так понимаю, в том, что NRE упадёт слишком поздно?
AP>Смысл -- сделать безопасным базовый/основополагающий прием трансформации кода Extract Method. Т.е. избежать катастрофы при использовании Extract Method, которая описана в первом посте.
Дело в том, что я не вижу никакой катастрофы.
Вот у нас был безопасный код — мы его отрефакторили. Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()? Значит, после рефакторинга код никак не поменяет свою работоспособность.

Вторая проблема: нигде в последующем обсуждении я не вижу примера того, как Extract Method станет более безопасным. Точнее, вообще нигде нет никаких Extract Method.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Вариант c OptionalValue:
AP>

AP>var x = Method1()
AP>    .ProcessValue(_ => _.Method2())
AP>    .ProcessValue(_ => _.Method3())
AP>    .ProcessValue(_ => _.Method4());
AP>

Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>> SQL Express 2008 R2

Здравствуйте, akasoft, Вы писали:

A>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?

Они не перловские, они хаскельные и окамловские. Иногда их употребление вполне уместно.

Здравствуйте, gandjustas, Вы писали:

G>Любая реализация Option должна быть изоморфна любой другой.
Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны.

G>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.
Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления?

Здравствуйте, akasoft, Вы писали:

AP>>Вариант c OptionalValue:
AP>>

AP>>var x = Method1()
AP>>    .ProcessValue(_ => _.Method2())
AP>>    .ProcessValue(_ => _.Method3())
AP>>    .ProcessValue(_ => _.Method4());
AP>>

A>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?
Стоит решить одну/две задачи с помощью такой конструкции, сравнить ее с альтернативной реализацией, и претензии отпадут сами собой.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, akasoft, Вы писали:

A>>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?

Q>Они не перловские, они хаскельные и окамловские. Иногда их употребление вполне уместно.
Разве что в ML языках　подчеркивание применяется в ситуациях, когда значение не используется. Здесь же подчеркивание есть имя используемой переменной.

Здравствуйте, Sinclair, Вы писали:

S>Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()?
Да, не было.

S>Дело в том, что я не вижу никакой катастрофы.
S>Вот у нас был безопасный код — мы его отрефакторили. Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()? Значит, после рефакторинга код никак не поменяет свою работоспособность.
Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е.

S>Вторая проблема: нигде в последующем обсуждении я не вижу примера того, как Extract Method станет более безопасным. Точнее, вообще нигде нет никаких Extract Method.
Извиняюсь, но этот абзац я не понял. В каких обсуждениях, какой пример? Пример с Extract Method-ом уже был в первом посте в разделе “Катастрофа при Extract Method”.

S>Точнее, вообще нигде нет никаких Extract Method.
В реальности этап с Extract Method-ом часто не присутствует в явном виде. Программист не рефакторит, а сразу пишет метод (или это делает вообще другой человек). Но описанная проблема присутствует и здесь. Надежность такого кода ниже по сравнению с тем, который получается после Inline Method.

Пример из реального проекта, где нужна ковариантность OptionalValue:

private static IOptionalValue<IFollowingPublicationCalculator> GetFollowingPublicationCalculator(
    string catalogNumber, string precededCatalogNumber, int releaseMark)
{
    if (string.IsNullOrEmpty(precededCatalogNumber))
    {
        return FindPreviousPublicationIdBySelfNumber(catalogNumber, releaseMark)
            .ProcessValue(value => new SelfNumberFollowingPublicationCalculator(value, catalogNumber));
    }
    else
    {
        return FindPreviousPublicationIdByOtherNumber(precededCatalogNumber)
            .ProcessValue(value => new OtherNumberFollowingPublicationCalculator(value, precededCatalogNumber));
    }
}

Так код будет выглядеть под C# 4.0. Причем сейчас этот код под C# 3.0, и я вырезал ручные операции с типами. Вариантов записи с ручными операциями над типами много, поэтому жду, какой вариант нравится вам. Мне все варианты не нравятся, хотя в них букв не много, и если будет достаточное обоснование, то можно смириться.

В варианте через абстрактный класс рассуждения про какой-то контракт это полная чушь, конечно. Но там есть другой приятный момент. Там есть implicit operator. Т.е. кое-где не будет требоваться вызов метода “.AsOptionalValue()”.

Вот думаю, что лучше ковариантность или implicit operator? Сделать и то и другое в текущей версии C#-а, к сожалению, нельзя.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Здравствуйте, gandjustas, Вы писали:

G>>Любая реализация Option должна быть изоморфна любой другой.
AP>Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны.
Это ковариантность не нужна, ты до сих пор пример привести не смог даже.
А вот согласованность получения значение option и проверки наличия значения очень даже нужны. Просто потому что они в других библиотеках так сделаны.

G>>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.
AP>Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления?
Не то сравниваешь. Тут вопрос согласованности, вот если ты сделаешь класс у которого не выполняется a.Equals(b) => a.GetHashCode() == b.GetHashCode(), то удивление будет ого-го, особенно при использовании в контейнерах.

Здравствуйте, Sinclair, Вы писали:

S> ... как Extract Method станет более безопасным. ...
Extract Method становится безопасным при использовании техники кодирования, описанной в разделе “Катастрофа при Extract Method”.

Здравствуйте, Alexander Polyakov, Вы писали:
AP>Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е.
Вы серъёзно? Лично мне описанный сценарий кажется слегка надуманным. Программист в здравом уме никогда даже не попробует заменить “new SomeClass1()” на “null”. Ни до рефакторинга, ни после.
Более реалистичным представляется замена new SomeClass1() на SomeClassFactory.Instance.GetInstance(). Но что-то мне подсказывает, что возврат null из SomeClassFactory не отловится ни компилятором, ни вашим OptionalValue.

AP>Извиняюсь, но этот абзац я не понял. В каких обсуждениях, какой пример? Пример с Extract Method-ом уже был в первом посте в разделе “Катастрофа при Extract Method”.
Нет примера того, как катастрофы Extract Method удаётся избежать при помощи OptionalValue. Может, я что-то пропустил?
Покажите мне код с экстрагированным методом, который упадёт при использовании OptionalValue, в отличие от кода без использования OptionalValue.

AP>В реальности этап с Extract Method-ом часто не присутствует в явном виде. Программист не рефакторит, а сразу пишет метод (или это делает вообще другой человек). Но описанная проблема присутствует и здесь. Надежность такого кода ниже по сравнению с тем, который получается после Inline Method.
Я, наверное, очень далёк уже от практики программирования. Я ни разу в жизни не наблюдал ошибки компилятора, о которой вы пишете. Как правило, мат ставится в два хода:
1. var x = null; // иногда — var x = GetSomeX(), который возвращает null
2. x.CallMethodRequiringNotNull(); // NRE

Против этого ваш OptionalValue ничего интересного не предлагает. Как, впрочем, и компилятор.

Здравствуйте, gandjustas, Вы писали:

G>Это ковариантность не нужна, ты до сих пор пример привести не смог даже.
Уже привел. Ковариантность нужна

.

G>>>Любая реализация Option должна быть изоморфна любой другой.
AP>>Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны.
G>... согласованность получения значение option и проверки наличия значения очень даже нужны. Просто потому что они в других библиотеках так сделаны.
Поведение моих реализаций согласовано с аналогичными реализациями в других библиотеках. Ты дописываешь свою реализацию, которую делаешь несогласованной с другими библиотеками. Почему претензии к результатам работы моего кода? Мой код делает ровно то, что заявлено, не больше, не меньше.

G>>>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.
AP>>Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления?
G>Не то сравниваешь. Тут вопрос согласованности, вот если ты сделаешь класс у которого не выполняется a.Equals(b) => a.GetHashCode() == b.GetHashCode(), то удивление будет ого-го, особенно при использовании в контейнерах.
Неплохая аналогия, да, тут надо делать согласованную реализацию двух методов. Аналогичные проблемы я отмечал для варианта, когда в интерфейсе IOptionalValue два свойства Value и HasValue. В моем коде у IOptionalValue метод один, поэтому согласовывать нечего.

Здравствуйте, Sinclair, Вы писали:

AP>>Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е.
S>Вы серъёзно? Лично мне описанный сценарий кажется слегка надуманным. Программист в здравом уме никогда даже не попробует заменить “new SomeClass1()” на “null”. Ни до рефакторинга, ни после.
S>Более реалистичным представляется замена new SomeClass1() на SomeClassFactory.Instance.GetInstance(). Но что-то мне подсказывает, что возврат null из SomeClassFactory не отловится ни компилятором, ни вашим OptionalValue.
Ага, я уже догадался, что вы напишете такое. И с некоторым запозданием я добавил комментарий:

Extract Method становится безопасным при использовании техники кодирования, описанной в разделе “Катастрофа при Extract Method”. http://rsdn.ru/forum/design/3955011.1.aspx
Автор: Alexander Polyakov
Дата: 12.09.10

Вы его заметили? Полное описание техники кодирования в первом посте. Если в вкратце, то это: не использование “return null(схематичное обозначение)” + OptionalValue.

S>Покажите мне код с экстрагированным методом, который упадёт при использовании OptionalValue, в отличие от кода без использования OptionalValue.
В абзаце выше уже написал, что OptionalValue в сочетании c не использованием “return null(схематичное обозначение)”.

AP>>Как правило, мат ставится в два хода:
S>1. var x = null; // иногда — var x = GetSomeX(), который возвращает null
S>2. x.CallMethodRequiringNotNull(); // NRE
Ага, именно это я и хотел показать Extract Method-ом, что проблема возникает как раз при разбиении задачи на два хода.

S>Против этого ваш OptionalValue ничего интересного не предлагает. Как, впрочем, и компилятор.
OptionalValue нацелен не напрямую на это. Его прямая цель -- реализация optional логики. Да, наверное, в заголовок лучше вынести последнее. Сейчас не самый удачный заголовок.

Здравствуйте, IT, Вы писали:

IT>Но без ПМ этим пользоваться не очень удобно.
Всё же чем не удобно? Я почти не знаком с pattern-matching, но пока я вижу, что в частном случае опциональных значений совпадении один к одному с OptionalValue. Например:
Pattern-matching

    match dict.TryGetValue "Brian" with 
    | Some(r) -> Console.WriteLine("Brian's favorite 32-bit integer is {0}", r) 
    | None    -> ()

http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!181.entry
OptionalValue

dict.GetValueEx("Brian").Process(
    r => Console.WriteLine("Brian's favorite 32-bit integer is {0}", r), 
   () => ()
);

Здравствуйте, gandjustas, Вы писали:

G>Ну это неверно. Maybe монада и была придумана, как средство описать частичные вычисления, которые могут не возвращать результат в некоторых случаях. Правда имеет смысл как можно дольше оставаться в этой самой монаде, а метод Process такой способностью не обладает.
В том то и дело, что для практических целей помимо самой монады важно то, как осуществляется выход из этой монады. Метод Process как раз и является безопасным выходом из монады в отличие от небезопасного GetValue.

К тому же, выяснилось, что в нашем частном случае pattern-matching совпал с методом Process http://rsdn.ru/forum/design/3955158.1.aspx

	От:	Alexander Polyakov
	Дата:	11.09.10 19:10
	Оценка:

	От:	Alexander Polyakov
	Дата:	11.09.10 19:23
	Оценка:

	От:	Alexander Polyakov
	Дата:	11.09.10 19:35
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	12.09.10 00:47
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	12.09.10 00:52
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	12.09.10 06:05
Оценка:

От:	Qbit86	https://twitter.com/qbit86
Дата:	12.09.10 08:00
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	12.09.10 10:00
Оценка: