softwarerДиезА в моем понимании - это всё метод transferMoneyFromPayerToRecipient()
Вот теперь Вы его хорошо назвали :) Именно сюда я и вёл. А теперь попробуйте его существенно переименовать, не меняя его поведения :)

Плохо ведете )))

Подойдет processPrimaryPayments() ? Или mainRemitment() ?
Или я могу вынести этот метод в отдельный интерфейс IMoneyTransferEngine и назвать apply().

А теперь объясните мне, чем первое название лучше? :)

softwarerДиезРазные разработчики могут понять смысл одного названия совершенно по-разному.
Не должно такого быть в хорошем коде. После того, как разработчик входит в курс дела - то есть воспринимает принятую в проекте терминологию, схему именования объектов итп - подобное расхождение будет.. удивительно.

ДиезИначе не нужна была бы документация с примерами :)
Документация с примерами нужна для описания более глубоких особенностей, не охватываемых названием.

Диез"Хорошо" или"плохо" назван идентификатор - это глубоко субъективное мнение.
Не соглашусь. Хорошесть измеряется тем, насколько легко члены команды, столкнувшись, понимают смысл этого идентификатора и насколько легко потом его вспоминают (то есть могут применить без поиска). Конечно, бывают экстравагантные схемы (скажем, я на всю жизнь запомнил из одного проекта функции naref() и daref() - они расшифровывались как "на резиденцию файла" и ... да, правильно, "дай резиденцию файла") - но и это куда лучше, чем когда метод giveMoneyToRecipient() может оказаться названным takeMoneyFromPayer().



Тут ключевая фраза "Не должно...". Но будет. И чем крупнее проект - тем больше.
А более формальное описание поведения в коде уменьшает влияние человеческого фактора.


softwarer
ДиезМы, надеюсь, обсуждаем не ваши личные предпочтения, а тему топика:
Эти два примера методов формально описывают два разных поведения, если не найден объект по идентификатору:
Формальное описание не является темой топика :) А к такому подходу мне сразу хочется спросить: а как поступать, если у объекта нужны оба этих метода?

Тема топика достаточно расплывчата, но мой пример не выходит за её рамки.
Если же я неправильно понял вопрос - пусть топикстартер меня поправит :)

Оба метода:




В чем проблема?

softwarerДиезПодойдет processPrimaryPayments() ?
Не очень. Абстрактно, я бы предположил, что transferMoneyFromPayerToRecipient - это метод, который вызывается из processPrimaryPayments (а также, вероятно, из processOtherPayments) после того, как осуществлены всякие проверки, оповещения и прочие действия, не связанные собственно с transfer.

ДиезИли mainRemitment() ?
Используете синонимы. Это противоречит правилам хорошего тона (выбирать терминологию и придерживаться её).

ДиезИли я могу вынести этот метод в отдельный интерфейс IMoneyTransferEngine и назвать apply()
Ничего не имею против. Сделаете интерфейс, сделаете у него методы setPayer, setRecipient, apply... вполне соответствует.

ДиезА теперь объясните мне, чем первое название лучше? :)
Чем что? На своём месте оно вполне хорошо. Сделаете интерфейс - там всё передербанится и станет хорошо apply.


Опять же, ваш персональный опыт диктует специфическое понимание каждого термина. Но разработать терминологию до начала проекта, и придерживаться ее в добровольно-принудительном порядке - это правильный подход. Тут согласен :)

softwarer
ДиезТут ключевая фраза "Не должно...". Но будет. И чем крупнее проект - тем больше.
Отнюдь. Зависит не от размеров проекта, а от бардачности его руководства.


ДиезА более формальное описание поведения в коде уменьшает влияние человеческого фактора.
Cкажу так: формальное описание должно быть хорошо спроектировано и дёшево в использовании, в противном случае его минусы начинают перевешивать плюсы.


Бардачность руководства испортит любой проект вне зависимости от технологий.
Но даже при адекватном руководстве, при росте количества персон, задействованных в проекте контроль становится всё сложнее, поэтому на помощь приходят технологические ограничения и ALM-инструменты.

Строгая типизация aka формализация типов - одно из таких ограничений. Вот и всё.

Монада Maybe давно придумана, обкатана и реализована для всех актуальных ЯП.
Минусы есть, конечно, каждый сам решает, что важнее.

softwarerДиезОба метода:


В чем проблема?
После того, как Вы поправили - ни в чём :) Но Вы, собственно, и пришли к той самой системе именования, против которой протестовали.

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

И опять же, я с самого начала не протестовал против систем наименования. Лишь считаю её второстепенной после типизации.

softwarer...
ДиезМонада Maybe давно придумана, обкатана и реализована для всех актуальных ЯП.
Минусы есть, конечно, каждый сам решает, что важнее.
Я бы отметил, что существование этого инструмента не убирает "человеческого фактора". То есть, допустим, мой подход:




Ваш подход




В общем-то, оба опираются на то, что один человек выполнит это требование, а другой - проверит, что оно выполнено, и напихает, если нет.
...
Не совсем понял ваше замечание, но попробую ответить, как понял ))

Суть в том, что переменной типа MyCustomer нельзя присвоить результат типа Option<MyCustomer> - это несовместимые типы, получим ошибку компиляции.
То есть придется делать явное преобразование, "разворачивать" Option в нужный тип.

А в вашем случае проверка на null лежит полностью на программисте, компилятор тут ничем не поможет.
Где забыл проверить, там получил exception.

softwarerДиезСуть в том, что переменной типа MyCustomer нельзя присвоить результат типа Option<MyCustomer> ... А в вашем случае проверка на null лежит полностью на программисте, компилятор тут ничем не поможет.
Для того, чтобы этот механизм сработал, программист должен выполнить правило "возвращай Option<MyCustomer>". И это лежит полностью на программисте, компилятор тут ничем не поможет.

Разумеется, программист должен решить, какой тип возвращать. Так же, как он должен решать, возвращать ли в методе int или string...

А когда он решил - правильное использование этого метода в вызывающем коде становится чуть проще, благодаря компилятору.

Остается, конечно, вариант, что программист по ошибке вернет null из метода, который должен возвращать не-Option значение.
Ну, тут только ждать NotNull аннотаций, про которые Petro123 говорил ))

softwarerДиезРазумеется, программист должен решить, какой тип возвращать. Так же, как он должен решать, возвращать ли в методе int или string...
Не так же. Смысловой тип в данном случае - MyCustomer. А Optional - это обёртка, и "не забыть" её - ровно такое же требование, как "не забыть" проверить результат метода find.

Обертка - неточное слово в данном случае. Это новый тип данных, несущий определенную смысловую нагрузку.

Имхо, логично воспринимать Option<T> как Collection<T> с числом элементов не более одного. Вы же не забываете возвращать TList<Customer> вместо Customer в случаях, когда это нужно? :)

softwarerДиезНу, тут только ждать NotNull аннотаций, про которые Petro123 говорил ))
В яве они давно есть. Но если честно, пользы не ощутил. Может, я слишком "старомодно воспитан".

Это Java как язык устарел, иначе не появлялись бы как грибы языки под JVM - Scala, Kotlin, Xtend, Ceylon... тыщи их ))

softwarerДиезИмхо, логично воспринимать Option<T> как Collection<T> с числом элементов не более одного.
Имхо, это игра словами.

Отнюдь :) И это не я придумал.

Функциональная имплементация Option реализует поведение итератора, который возвращает 0 или 1 элемент.
Помимо прочего, это позволяет вот такие полезные конструкции:



Как видите, прямая аналогия с коллекциями.

softwarer
Диез Вы же не забываете возвращать TList<Customer> вместо Customer в случаях, когда это нужно? :)
У них принципиально разная семантика. Ваш пример гораздо ближе требованию возвращать Integer вместо int - согласитесь, нетрудно и перепутать.


Я понимаю, вы про Java?
Да, в некотором роде, Integer можно рассматривать как Nullable(int), и, кстати, до появления автобоксинга компилятор требовал явного приведения типов...
Но семантика их одинаковая, в отличие от Option, который явно определяет возможность отсутствия значения (и это его единственная функция).

К Option<T> по изначальному смыслу намного ближе концепция "NULL" и "NOT NULL" в СУБД. Поведение в обоих случаях задается явно; "забыть" написать NOT NULL означает ошибку проектирования.

softwarerДиезЭто Java как язык устарел,
Странно. По мне, он только к седьмой версии дошёл до состояния "можно пользоваться без отвращения".

Диезиначе не появлялись бы как грибы языки под JVM - Scala, Kotlin, Xtend, Ceylon... тыщи их ))
Никакой связи. JVM удобна тем, что любой, кто хочет создать свой язык, может компилить под неё и не заморачиваться с машинным кодом. Соответственно, наличие таких энтузиастов никак не связано с состоянием собственно явы.

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

softwarerДиезФункциональная имплементация Option реализует поведение итератора,
Это очевидное техническое решение, которое не имеет ни малейшего отношения к восприятию. Скажем, по аналогии, у меня был объект "фильтр", который тоже реализовал поведение итератора: получал коллекцию на вход и подмножество отдавал на выход. Но это совершенно не значит, что он "воспринимался как коллекция". С тем же успехом вахтёра на входе в здание можно воспринимать как коллекцию


Тут вы используете слишком вольную трактовку понятия "коллекция" :) Объект "Фильтр" никак не может быть коллекцией (хотя понятно, что его методы вполне могут принимать и возвращать коллекции).

Чтобы показать это, достаточно задать простой вопрос: коллекцией ЧЕГО является объект "Фильтр" ? Или коллекцией ЧЕГО является вахтер?

Про объект Option<String> можно легко сказать, что он является коллекцией строк , но с конкретным ограничением: коллекция либо пустая, либо содержит ровно один элемент.

softwarerДиезНо семантика их одинаковая, в отличие от Option, который явно определяет возможность отсутствия
Integer ровно так же "явно определяет возможность отсутствия".

ДиезПоведение в обоих случаях задается явно; "забыть" написать NOT NULL означает ошибку проектирования.
Верно, только это не делает истинным то Ваше утверждение, которое мы обсуждаем. Напомню, Вы пытаетесь доказать, что INTEGER и INTEGER NOT NULL - это "семантически разные типы", которые так же сложно спутать, как например int и String или там int и Vector<int>.

Как правильно заметил выше мембер F#, это зависит от языка :)
В языках с "сильной" типизацией вообще не используется понятие null, а "INTEGER" и "INTEGER NOT NULL" - совершенно разные типы.

Если в таком языке метод возвращает тип MyCustomer, то его результатом может быть только объект типа MyCustomer (или любого наследника, но это не принципиально).

Если вдруг функциональные требования к методу поменялись, и возвращаемое значение теперь необязательно, то сигнатуру метода придется поменять на Option<MyCustomer>. И весь внешний код, использующий этот метод, придется адаптировать к новым требованиям, иначе не скомпилируется...