Re[9]: Optional Value. Уменьшение количества null reference-
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.09.10 06:56
Оценка: +1
Здравствуйте, Alexander Polyakov, Вы писали:

AP>Я про реализацию optional логики, выше выделил жирным. Причем тут присвоение null-ов?

Если вы про реализацию optional логики, то и пишите про реализацию optional логики. И приводите примеры про реализацию optional логики.
А вы сначала пишете про "избавиться от null", и про "безопасность Extract Method". Потом резко переходите к некоему решению, безо всякой логической связи с избавлением от null-ов и Extract Method.
Убедительного примера про optional логику я тоже не вижу. Пример с method1().method2().method3() прекрасно работает безо всякого OptionalValue.

AP>Что ваш Mandatory<T> предлагает для реализации optional логики? Передачу null-ов и “водопроводный” код, разобранный выше?

Для optional логики он предлагает передачу null-ов. На водопроводном коде он не настаивает. К примеру, вполне будет работать вот такой код:
var x = Method1()
    .ProcessValue(_ => _.Method2())
    .ProcessValue(_ => _.Method3())
    .ProcessValue(_ => _.Method4());

Зачем здесь OptionalValue?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 14.09.10 10:08
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Если вы про реализацию optional логики, то и пишите про реализацию optional логики. И приводите примеры про реализацию optional логики.

Да, я уже отметил, что акцент в первую очередь надо было сделать на реализации optional логики. Это была моя ошибка. Но форум как раз и служит для такого рода диалога.

Сейчас я пришел к тому, что акцент надо делать просто на передачу необязательных значений между разными scope-ами: между методами, внутри одного метода и т.п. Показать, что OptionalValue предлагает безопасный способ передачи значений между scope-ами.

S>>А вы сначала пишете про "избавиться от null", и про "безопасность Extract Method". Потом резко переходите к некоему решению, безо всякой логической связи с избавлением от null-ов и Extract Method.

Опишите полную картину для вашей реализации через Mandatory<T>, и, возможно, увидите связи и в моем описании. Например, см. мой вопрос ниже. Но в целом, да, согласен, описание надо переделать.

AP>>>Что ваш Mandatory<T> предлагает для реализации optional логики? Передачу null-ов и “водопроводный” код, разобранный выше?

S>>Для optional логики он предлагает передачу null-ов. На водопроводном коде он не настаивает. К примеру, вполне будет работать вот такой код:
S>>
S>>var x = Method1()
S>>    .ProcessValue(_ => _.Method2())
S>>    .ProcessValue(_ => _.Method3())
S>>    .ProcessValue(_ => _.Method4());
S>>

S>>Зачем здесь OptionalValue?
Про это я уже отписался тут:

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


Вы будете писать везде “a1.ProcessValue(_ => _.SomeMethod())”, где источник (переменная “a1”) не Mandatory<T>? Вы это предлагаете?
Re[11]: Optional Value. Уменьшение количества null reference
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.09.10 11:53
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

AP>Сейчас я пришел к тому, что акцент надо делать просто на передачу необязательных значений между разными scope-ами: между методами, внутри одного метода и т.п. Показать, что OptionalValue предлагает безопасный способ передачи значений между scope-ами.

Покажите. Пока что я этого не вижу. Семантика OptionalValue — точно такая же, как и в случае обычного T:class.

AP>Опишите полную картину для вашей реализации через Mandatory<T>, и, возможно, увидите связи и в моем описании.

Я не понимаю что такое "полная картина". Для того, чтобы приведённый код c ProcessValue заработал, достаточно написать один тривиальный extension method. Вам его привести?

AP>Ага, я это знаю . Только остается вопрос, когда такой записью пользоваться? Для всех переменных? Нет, спасибо, не буду.

Почему для всех? Только для optional. Во всех остальных местах меняйте на Mandatory<> и наслаждайтесь.

AP>OptionalValue как раз и служит для разделение опциональных и не опциональных переменных. Соответственно, для первых применяем такую запись, а для вторых обычную. А какой будет переменная T или IOptionalValue<T> определяет поставщик переменной. Если мы знаем, что поставщик соблюдает это правило, то для T можно не беспокоиться об NRE. Если поставщик не соблюдает это правило, то все как обычно, т.е. хреново: писать или не писать if, если писать, то, что внутри этого if-а делать и т.д. Глупость заключается в том, чтобы создавать эту хреновую ситуацию и в случае, если вы сами являетесь тем поставщиком.

AP>http://www.rsdn.ru/forum/design/3954267.1.aspx
Автор: Alexander Polyakov
Дата: 11.09.10

AP>[/q]

AP>Вы будете писать везде “a1.ProcessValue(_ => _.SomeMethod())”, где источник (переменная “a1”) не Mandatory<T>? Вы это предлагаете?

Совершенно верно. По крайней мере, нам не нужно гадать, соблюдает поставщик правила или нет. В вашем случае совершенно невозможно понять, случайно или намеренно был опущен ProcessValue.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 15.09.10 12:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

AP>>Сейчас я пришел к тому, что акцент надо делать просто на передачу необязательных значений между разными scope-ами: между методами, внутри одного метода и т.п. Показать, что OptionalValue предлагает безопасный способ передачи значений между scope-ами.

S>Покажите. Пока что я этого не вижу. Семантика OptionalValue — точно такая же, как и в случае обычного T:class.
Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами. Допустим, мы можем получить некоторое значение “var value = ...” только при определенном условии “someCondition”. Причем получение значения происходит в одном скоупе Scope1, а использование в другом Scope2. Пишем вот такой код:
Type1 outerValue;

#region Scope1

if (someCondition)
{
    var value = ... 
    outerValue = value;
}

#endregion End of Scope1

#region Scope2

Console.WriteLine(outerValue.Name);

#endregion End of Scope2
Упс, строка “Console.WriteLine(outerValue.Name)” не компилируется:

Error 1 Use of unassigned local variable 'outerValue'

Что же делать? Если написать:
if (someCondition)
{
    var value = ...
    outerValue = value;
}
else
{
    outerValue = null;
}
то получим NRE в Scope2.
Вспоминаем, что есть Nothing. Пишем его:
if (someCondition)
{
    var value = ...;
    outerValue = value;
}
else
{
    outerValue = OptionalValue.Nothing<Type1>();
}
Не компилируется. Меняем тип переменной outerValue на IOptionalValue<Type1>:
IOptionalValue<Type1> outerValue;

#region Scope1

if (someCondition)
{
    var value = ...
    outerValue = value.AsOptionalValue();
}
else
{
    outerValue = OptionalValue.Nothing<Type1>();
}

#endregion End of Scope1

#region Scope2

Console.WriteLine(outerValue.Name);

#endregion End of Scope2
Теперь не компилируется Scope2 (строка “outerValue.Name”). Для работы с IOptionalValue переменными используется метод Process. Используем его.
IOptionalValue<Type1> outerValue;

#region Scope1

if (someCondition)
{
    var value = ...;
    outerValue = value.AsOptionalValue();
}
else
{
    outerValue = OptionalValue.Nothing<Type1>();
}

#endregion End of Scope1

#region Scope2

outerValue.Process(
    value => Console.WriteLine(value.Name)
    );

#endregion End of Scope2
Опять не компилируется. Метод Process требует второй аргумент. Ставим TODO.
IOptionalValue<Type1> outerValue;

#region Scope1

if (someCondition)
{
    var value = ...;
    outerValue = value.AsOptionalValue();
}
else
{
    outerValue = OptionalValue.Nothing<Type1>();
}

#endregion End of Scope1

#region Scope2

outerValue.Process(
    value => Console.WriteLine(value.Name),
    () =>
        {
            //TODO: implement this
            throw new NotImplementedException();
        }
    );

#endregion End of Scope2
Далее думаем, ..., смотрим документы с требованиями к продукту, по необходимости общаемся с бизнес-аналитиком, заказчиком и т.д. В результате этого процесса получаем ответ на вопрос, что делать в случае, помеченном TODO. И реализуем это TODO.

С этого момента OptionalValue я позиционирую как безопасный способ передачи необязательного значения между разными scope-ами. Темы упомянутые ранее: не являются первичными.


Относительно Mandatory<T> отпишусь чуть позже. ... Если кратко, то на практике это не пойдет.
Re[13]: Optional Value. Уменьшение количества null reference
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.09.10 17:45
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

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


AP>>>Сейчас я пришел к тому, что акцент надо делать просто на передачу необязательных значений между разными scope-ами: между методами, внутри одного метода и т.п. Показать, что OptionalValue предлагает безопасный способ передачи значений между scope-ами.

S>>Покажите. Пока что я этого не вижу. Семантика OptionalValue — точно такая же, как и в случае обычного T:class.
AP>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами. Допустим, мы можем получить некоторое значение “var value = ...” только при определенном условии “someCondition”. Причем получение значения происходит в одном скоупе Scope1, а использование в другом Scope2. Пишем вот такой код:
AP>Type1 outerValue;

AP>#region Scope1

AP>if (someCondition)
AP>{
AP>    var value = ... 
AP>    outerValue = value;
AP>}

AP>#endregion End of Scope1

AP>#region Scope2

AP>Console.WriteLine(outerValue.Name);

AP>#endregion End of Scope2
AP>
Упс, строка “Console.WriteLine(outerValue.Name)” не компилируется:

AP>

AP>Error 1 Use of unassigned local variable 'outerValue'

Что же делать? Если написать:


А чего бы не написать
if (someCondition)
{
    var value = ... 
    Console.WriteLine(outerValue.Name);
}

???
Re[14]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 15.09.10 19:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А чего бы не написать

G>
G>if (someCondition)
G>{
G>    var value = ... 
G>    Console.WriteLine(outerValue.Name);
G>}
G>

G>???
В рамках рассматриваемого примера это по условию задачи:

Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.


Пример демонстрирует возможности инструмента.
Re[15]: Optional Value. Уменьшение количества null reference
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 16.09.10 05:24
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

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


G>>А чего бы не написать

G>>
G>>if (someCondition)
G>>{
G>>    var value = ... 
G>>    Console.WriteLine(outerValue.Name);
G>>}
G>>

G>>???
AP>В рамках рассматриваемого примера это по условию задачи:

AP>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.


AP>Пример демонстрирует возможности инструмента.


Надо подходить со стороны решения задачи, а не демонстрации возможностей на выдуманом примере.

Если рассмотреть твою задачу: надо выполнить разные действия в зависимости от условия. Это решается банальным if-ом.
Re[12]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 20.09.10 15:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

AP>>Опишите полную картину для вашей реализации через Mandatory<T>, и, возможно, увидите связи и в моем описании.

S>Я не понимаю что такое "полная картина". Для того, чтобы приведённый код c ProcessValue заработал, достаточно написать один тривиальный extension method. Вам его привести?
Его уже приводили в этом треде. Я такое писал (на другом форуме) еще года 4 назад.

AP>>Опишите полную картину для вашей реализации через Mandatory<T>, и, возможно, увидите связи и в моем описании.

S>Я не понимаю что такое "полная картина".
S>...
AP>>Ага, я это знаю . Только остается вопрос, когда такой записью пользоваться? Для всех переменных? Нет, спасибо, не буду.
S>Почему для всех? Только для optional. Во всех остальных местах меняйте на Mandatory<> и наслаждайтесь.
В прошлом сообщении
Автор: Alexander Polyakov
Дата: 15.09.10
я написал, что Mandatory<T> не будет работать на практике. Теперь прокомментирую свой вывод. Я думаю, что проще всего это показать, разобрав несколько секунд из жизни программиста и кода.

Сейчас программист пишет вот так:
new SomeClass1().SomeMethod1();
Выделяем некоторый кусок кода (например, “new SomeClass1()”) и наживаем “Extract Method”:
В результате получаем:
static void Main()
{
    ExtractedMethod1().SomeMethod1();
}

private static SomeClass1 ExtractedMethod1()
{
    return new SomeClass1();
}


Вы можете описать подробно step by step рассмотренные несколько секунд из жизни программиста и кода при применении Mandatory?
Re[16]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 20.09.10 15:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>А чего бы не написать

G>>>
G>>> ... 
G>>>

G>>>???
AP>>В рамках рассматриваемого примера это по условию задачи:

AP>>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.

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

G>Если рассмотреть твою задачу: надо выполнить разные действия в зависимости от условия. Это решается банальным if-ом.

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

В моем примере разделение на scope-ы, например, позволяет вынести любой scope в отдельный метод.
Re[17]: Optional Value. Уменьшение количества null reference
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.09.10 18:06
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

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


G>>>>А чего бы не написать

G>>>>
G>>>> ... 
G>>>>

G>>>>???
AP>>>В рамках рассматриваемого примера это по условию задачи:

AP>>>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.

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

G>>Если рассмотреть твою задачу: надо выполнить разные действия в зависимости от условия. Это решается банальным if-ом.

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

AP>В моем примере разделение на scope-ы, например, позволяет вынести любой scope в отдельный метод.

Только ты не написал для чего тебе разные скоупы, те банально высосал проблему из пальца.
Re[13]: Optional Value. Уменьшение количества null reference
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.09.10 05:47
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:


AP>Сейчас программист пишет вот так:

AP>
AP>new SomeClass1().SomeMethod1();
AP>
Выделяем некоторый кусок кода (например, “new SomeClass1()”) и наживаем “Extract Method”:

AP>В результате получаем:
AP>static void Main()
AP>{
AP>    ExtractedMethod1().SomeMethod1();
AP>}

AP>private static SomeClass1 ExtractedMethod1()
AP>{
AP>    return new SomeClass1();
AP>}
AP>


AP>Вы можете описать подробно step by step рассмотренные несколько секунд из жизни программиста и кода при применении Mandatory?

Могу, только без скриншотов.
1. программист пишет вот так:
SomeClass1.New().Value.SomeMethod1()

2. Выделяем SomeClass1.New() и нажимаем Extract Method
3. В результате получаем:
static void Main()
{
  ExtractedMethod1().Value.SomeMethod1();
}
private static Mandatory<SomeClass1> ExtractedMethod1()
{
  return SomeClass1.New();
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 21.09.10 10:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Могу, только без скриншотов.

Да, то что нужно.

S>1. программист пишет вот так:

S>
S>SomeClass1.New().Value.SomeMethod1()
S>

Таким образом, вы подменяете стандартную для языка процедуру -- вызов публичного конструктора во внешнем коде. Тут требуется формулировка правила/полиси/конвеншена для повсеместного применения. Когда? Где? Зачем? делать такую подмену?

В рамках рассматриваемого примера мы получили усложнение в чистом виде, а выгода нулевая.
Re[15]: Optional Value. Уменьшение количества null reference
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.09.10 10:37
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

S>>1. программист пишет вот так:

S>>
S>>SomeClass1.New().Value.SomeMethod1()
S>>

AP>Таким образом, вы подменяете стандартную для языка процедуру -- вызов публичного конструктора во внешнем коде. Тут требуется формулировка правила/полиси/конвеншена для повсеместного применения. Когда? Где? Зачем? делать такую подмену?
Для решения проблемы "избавление от null".
В жизни, конечно же, ваш синтетический пример не встречается. Если программист делает вызов на анонимном объекте, то он практически никогда в жизни не будет делать Extract Method и проблема абсолютно надумана.
А как только у нас появляется именованный объект, у нас появляется возможность указать любую policy с точно такими же затратами, как в вашем случае. То есть во всяком месте, где у нас требуется гарантия наличия значения, мы пишем Mandatory<T> и всё.


AP>В рамках рассматриваемого примера мы получили усложнение в чистом виде, а выгода нулевая.

Ну покажите теперь ваш же пример с IOptionalValue. И посмотрим, у кого усложнение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 21.09.10 11:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>>>А чего бы не написать

G>>>>>
G>>>>> ... 
G>>>>>

G>>>>>???
AP>>>>В рамках рассматриваемого примера это по условию задачи:

AP>>>>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.

AP>>>>Пример демонстрирует возможности инструмента.
G>>>Надо подходить со стороны решения задачи, а не демонстрации возможностей на выдуманом примере.
AP>>Именно так ! В задаче четко прописано некоторое условие, ты его пытаешься отбросить и формулируешь другую задачу.
G>Нет, я именно формулирую задачу, а ты приводишь детали реализации, относящиеся непонятно к чему.
Открываем мой пост
Автор: Alexander Polyakov
Дата: 15.09.10
. В начале идет четкая формулировка задачи. Затем ее реализация. Какие детали реализации ты не можешь связать с условием задачи?

AP>>В моем примере разделение на scope-ы, например, позволяет вынести любой scope в отдельный метод.

G>Только ты не написал для чего тебе разные скоупы, те банально высосал проблему из пальца.
Практикующий программист понимает, что scope-ы могут понадобиться для различных целей: для выделения в отдельные методы, для использования внутри охватывающего using-а и т.п. Поэтому писать для чего нужны скоупы это загромождать пример лишними атрибутами.
Re[19]: Optional Value. Уменьшение количества null reference
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.09.10 11:07
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

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


G>>>>>>А чего бы не написать

G>>>>>>
G>>>>>> ... 
G>>>>>>

G>>>>>>???
AP>>>>>В рамках рассматриваемого примера это по условию задачи:

AP>>>>>Ok, продемонстрирую безопасный способ передачи необязательного значения между разными scope-ами.

AP>>>>>Пример демонстрирует возможности инструмента.
G>>>>Надо подходить со стороны решения задачи, а не демонстрации возможностей на выдуманом примере.
AP>>>Именно так ! В задаче четко прописано некоторое условие, ты его пытаешься отбросить и формулируешь другую задачу.
G>>Нет, я именно формулирую задачу, а ты приводишь детали реализации, относящиеся непонятно к чему.
AP>Открываем мой пост
Автор: Alexander Polyakov
Дата: 15.09.10
. В начале идет четкая формулировка задачи. Затем ее реализация. Какие детали реализации ты не можешь связать с условием задачи?



безопасный способ передачи необязательного значения между разными scope-ами

Ты считаешь это формулировкой задачи?

Хотя бы опиши какое поведение должно наблюдаться.

AP>>>В моем примере разделение на scope-ы, например, позволяет вынести любой scope в отдельный метод.

G>>Только ты не написал для чего тебе разные скоупы, те банально высосал проблему из пальца.
AP>Практикующий программист понимает, что scope-ы могут понадобиться для различных целей: для выделения в отдельные методы, для использования внутри охватывающего using-а и т.п. Поэтому писать для чего нужны скоупы это загромождать пример лишними атрибутами.
Практикующий программист понимает что разные скоупы можно свести к одному и не плодить сущности без нужды.

Приведи пример задачи где эти скоупы необходимы. Ты же "Практикующий программист", у тебя должно быть много таких примеров.
Re[16]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 21.09.10 22:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

AP>>Таким образом, вы подменяете стандартную для языка процедуру -- вызов публичного конструктора во внешнем коде. Тут требуется формулировка правила/полиси/конвеншена для повсеместного применения. Когда? Где? Зачем? делать такую подмену?

S>Для решения проблемы "избавление от null".
Замечу, что в этом треде такая задача ни разу не ставилась.

AP>>Таким образом, вы подменяете стандартную для языка процедуру -- вызов публичного конструктора во внешнем коде. Тут требуется формулировка правила/полиси/конвеншена для повсеместного применения. Когда? Где? Зачем? делать такую подмену?

S>Для решения проблемы "избавление от null".
S>В жизни, конечно же, ваш синтетический пример не встречается. Если программист делает вызов на анонимном объекте, то он практически никогда в жизни не будет делать Extract Method и проблема абсолютно надумана.
S>А как только у нас появляется именованный объект, у нас появляется возможность указать любую policy с точно такими же затратами, как в вашем случае. То есть во всяком месте, где у нас требуется гарантия наличия значения, мы пишем Mandatory<T> и всё.
Во-первых, причем тут Extract Method, мои вопросы, на которые вы отвечали, касались исключительно первой строки в вашем коде. Или в вашем коде второй пункт оказывает влияние на первую строчку? Если так, то это совсем хреново.
Во-вторых, если первую строчку в моем примере написать вот так:
var someClass1 = new SomeClass1();
someClass1.SomeMethod1();
Это что-то принципиально поменяет? Если да, то распишите step by step и этот вариант.

AP>>В рамках рассматриваемого примера мы получили усложнение в чистом виде, а выгода нулевая.

S>Ну покажите теперь ваш же пример с IOptionalValue. И посмотрим, у кого усложнение.
В текущем примере нет необязательных значений, поэтому код примера остается неизменным.

S>... с точно такими же затратами, как в вашем случае. ...

Рассматриваемый пример показал обратное: у меня затраты нулевые, у вас ненулевые.

Сделаю некоторый комментарий относительно OptionalValue. Главный ресурс, который стоит экономить, это умственные усилия программиста. При использовании OptionalValue программисту нет необходимости задумываться над расстановкой T или IOptionalValue<T>, фактически это делается под однозначным управлением со стороны компилятора или ReSharper-а. Всё начинается с того, что в одной из веток кода у нас нет подходящего значения для возврата, тогда мы пишем Nothing. А далее компилятор (или ReSharper) нас ведет “за руку” по однозначному пути. Пример такого процесса был продемонстрирован тут
Автор: Alexander Polyakov
Дата: 15.09.10
.
Re[17]: Optional Value. Уменьшение количества null reference
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.09.10 05:13
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

S>>А как только у нас появляется именованный объект, у нас появляется возможность указать любую policy с точно такими же затратами, как в вашем случае. То есть во всяком месте, где у нас требуется гарантия наличия значения, мы пишем Mandatory<T> и всё.

AP>Во-первых, причем тут Extract Method, мои вопросы, на которые вы отвечали, касались исключительно первой строки в вашем коде.
А мне казалось, что Extract Method является неотъемлемой частью вашей задачи. Если нет — дайте другой пример, без Extract Method.

AP>Во-вторых, если первую строчку в моем примере написать вот так:
AP>var someClass1 = new SomeClass1();
AP>someClass1.SomeMethod1();
AP>
Это что-то принципиально поменяет? Если да, то распишите step by step и этот вариант.

Конечно поменяет. Как только нам потребуется гарантия невылета null при использовании, мы заменим var на Mandatory<SomeClass1>. А дальше всё сделает компилятор и среда.

S>>Ну покажите теперь ваш же пример с IOptionalValue. И посмотрим, у кого усложнение.

AP>В текущем примере нет необязательных значений, поэтому код примера остается неизменным.
А как же "катастрофа с null", которую кто-то так красочно расписывал неделю назад?
AP>Рассматриваемый пример показал обратное: у меня затраты нулевые, у вас ненулевые.
Ну, если вот так передёргивать, то всегда можно показать обратное.

AP>Сделаю некоторый комментарий относительно OptionalValue. Главный ресурс, который стоит экономить, это умственные усилия программиста. При использовании OptionalValue программисту нет необходимости задумываться над расстановкой T или IOptionalValue<T>, фактически это делается под однозначным управлением со стороны компилятора или ReSharper-а. Всё начинается с того, что в одной из веток кода у нас нет подходящего значения для возврата, тогда мы пишем Nothing. А далее компилятор (или ReSharper) нас ведет “за руку” по однозначному пути. Пример такого процесса был продемонстрирован тут
Автор: Alexander Polyakov
Дата: 15.09.10
.

Интересная гипотеза. Неплохо бы как-то обосновать то, что источником заметного процента null-ов у нас является "отсутствие подходящего значения". Потому что в моём опыте гораздо чаще происходит неявное присваивание null. Например, как-то так:

var settings = new SomeSettings();
if (someCondition)
  settings.Loader = new FileLoader();
...
settings.Loader.Load(fileName);

Здесь при невыполнении условия Loader останется проинициализированным по умолчанию. И мы имеем настоящую, а не воображаемую, катастрофу с null. Отладка её особенно неприятна потому, что строчка с Loader.Load может встретиться где угодно — совершенно не в том методе, где была совершена ошибка. Объявление Loader как Mandatory<ILoader> позволяет мне гарантировать, что никаких null там не будет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Optional Value. Уменьшение количества null reference
От: Alexander Polyakov  
Дата: 22.09.10 12:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>А как только у нас появляется именованный объект, у нас появляется возможность указать любую policy с точно такими же затратами, как в вашем случае. То есть во всяком месте, где у нас требуется гарантия наличия значения, мы пишем Mandatory<T> и всё.

AP>>Во-первых, причем тут Extract Method, мои вопросы, на которые вы отвечали, касались исключительно первой строки в вашем коде.
S>А мне казалось, что Extract Method является неотъемлемой частью вашей задачи. Если нет — дайте другой пример, без Extract Method.
Мой пример являлся только отправной точкой, и он прекрасно выполнил свою роль. Пример выявил, что вместо вызова публичного конструктора во внешнем коде вы предлагаете писать статический метод New(). Я прошу у вас сформулировать и обосновать policy для повсеместного использования этого подхода. Или у вас нет policy на счет замены конструктора на New()?
Кстати, как будут выглядеть ваш код и policy, если нет возможности дописывать статические методы, например, при использовании конструкторов классов из .Net Framework-а?

S>... мы заменим var на Mandatory<SomeClass1> ...

Ага, теперь уже и “var” нельзя использовать. И наш язык программирования начинает помаленьку рассыпаться.

S>... Как только нам потребуется гарантия невылета null при использовании ...

Странное предложение. Если логика задачи такова, что во всех ветках существует нормальное значение для возврата, то, естественно, хочется иметь такую гарантию ВСЕГДА (если гарантия не очень дорого стоит). То есть определяющей точкой служит наличие нормальных значений, а не потребность в какой-то гарантии.

S>А как же "катастрофа с null", которую кто-то так красочно расписывал неделю назад?

У меня было “Катастрофа при Extract Method”, “уменьшение количества null reference-ов”. “Катастрофы с null” не было. О каком красочном описании вы говорите? Все ходы записаны, можете перечитать.
В принципе, описание в первом посте получилось не очень удачным, но чего не было, того не было.

AP>>Рассматриваемый пример показал обратное: у меня затраты нулевые, у вас ненулевые.

S>Ну, если вот так передёргивать, то всегда можно показать обратное.
Это не передергивание. А всего лишь демонстрация на примере того, что у вашего подхода с Mandatory<T> нет прямого обоснования. Есть только косвенное обоснование. А такие приемы и policy плохо приживаются на практике.

S>Интересная гипотеза. Неплохо бы как-то обосновать то, что источником заметного процента null-ов у нас является "отсутствие подходящего значения". Потому что в моём опыте гораздо чаще происходит неявное присваивание null. Например, как-то так:

S>
S>var settings = new SomeSettings();
S>if (someCondition)
S>  settings.Loader = new FileLoader();
S>...
S>settings.Loader.Load(fileName);
S>

S>Здесь при невыполнении условия Loader останется проинициализированным по умолчанию. И мы имеем настоящую, а не воображаемую, катастрофу с null. Отладка её особенно неприятна потому, что строчка с Loader.Load может встретиться где угодно — совершенно не в том методе, где была совершена ошибка. Объявление Loader как Mandatory<ILoader> позволяет мне гарантировать, что никаких null там не будет.
Отмечу, что кое-что на этот счет я писал в первом посте:

Все null-ы мы таким образом не истребим, поскольку
a. field-ы классов инициализируются null-ами,
b. оператор "as" возвращает null,
c. уже имеющиеся библиотеки поставляют null-ы.
Но наша цель более скромная – уменьшить количество null-ов. Кстати, по пунктам a и b еще можно кое-что отвоевать.
http://rsdn.ru/forum/design/3952383.flat.aspx



S>Интересная гипотеза. Неплохо бы как-то обосновать то, что источником заметного процента null-ов у нас является "отсутствие подходящего значения". Потому что в моём опыте гораздо чаще происходит неявное присваивание null. Например, как-то так:

S>
S>var settings = new SomeSettings();
S>if (someCondition)
S>  settings.Loader = new FileLoader();
S>...
S>settings.Loader.Load(fileName);
S>

S>Здесь при невыполнении условия Loader останется проинициализированным по умолчанию. И мы имеем настоящую, а не воображаемую, катастрофу с null.
Во-первых, этот процент зависит от стиля кодирования. Например, я в последние годы стараюсь как можно реже использовать не readonly состояние. В вашем примере “settings.Loader” это изменяемое состояние. Изменяемое состояние приводит к гораздо более широкому кругу проблем, чем null-ы.

Во-вторых, процент зависит от задачи.

Учитывая эти замечания, я думаю, что оценкой этого процента надо заниматься в рамках конкретного проекта. Я лишь предлагаю инструмент, а выбирать между различными вариантами вам. По моему опыту OptionalValue достаточно востребованная вещь, мы используем его в своих проектах. OptionalValue лежит себе никому не мешает, есть не просит, к нему обращаются только, если появилась ситуация, когда нет нормального значения для возврата. И в этом случае OptionalValue нам верно служит, делая работу с такой ситуацией безопасной.

S>Здесь при невыполнении условия Loader останется проинициализированным по умолчанию. ... Объявление Loader как Mandatory<ILoader> позволяет мне гарантировать, что никаких null там не будет.

Как Mandatory спасет от null-ов, которые появляются при инициализации по умолчанию? Продемонстрируйте строчками кода.
Re[19]: Optional Value. Уменьшение количества null reference
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.09.10 12:41
Оценка:
Здравствуйте, Alexander Polyakov, Вы писали:

S>>... мы заменим var на Mandatory<SomeClass1> ...

AP>Ага, теперь уже и “var” нельзя использовать.
Можно, отчего же. Если вам удобнее, то пишите
var x = (new SomeClass1).AsMandatory();


S>>А как же "катастрофа с null", которую кто-то так красочно расписывал неделю назад?

AP>У меня было “Катастрофа при Extract Method”, “уменьшение количества null reference-ов”. “Катастрофы с null” не было. О каком красочном описании вы говорите?
См. топикстарт.

AP>Это не передергивание. А всего лишь демонстрация на примере того, что у вашего подхода с Mandatory<T> нет прямого обоснования. Есть только косвенное обоснование. А такие приемы и policy плохо приживаются на практике.

Возможно.

AP>Во-первых, этот процент зависит от стиля кодирования. Например, я в последние годы стараюсь как можно реже использовать не readonly состояние. В вашем примере “settings.Loader” это изменяемое состояние. Изменяемое состояние приводит к гораздо более широкому кругу проблем, чем null-ы.

Да, возможно. Допускаю, что использование OptionalValue в проектах с функциональным стилем может быть оправдано. Т.к. null вызывает проблемы в основном при изменяемом состоянии. Если состояние неизменяемое, то найти того, кто отдал null, нетрудно.

AP>Как Mandatory спасет от null-ов, которые появляются при инициализации по умолчанию? Продемонстрируйте строчками кода.

Надо подумать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Optional Value. Уменьшение количества null reference-
От: vdimas Россия  
Дата: 23.09.10 07:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

Да, именно. Уверен, многие делали подобные хелперы. В моем похожем варианте базовым был интерфейс, а два реализатора на struct, что в случаях, доступных компилятору, делает всё на один уровень косвенности меньше.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.