Alexander
Single Responsibiltiy
Dmitry
нормально, особенно тут хорошо тайпклассы заходят
Alexander
low coupling, high cohesion
Dmitry
ну, большие приложения в тыкву превращаются без модульности
Dmitry
а модульность может достигаться разными способами
Alexander
Модульность - это важно. Но этого недостаточно для приложения, общающегося с внешним миром.
кана
Сгенерировать pdf - это метод для Invoice DSL. У меня такой даже есть, обращается к сервису.
Посчитать total - это сценарий, так как ему требуются данные по инвойсам, которые он может получить, дергая методы DSL. Общее правила для DSL такие:
- Методы должны делать только то, что нельзя выразить через другие методы;
- Методы должны быть настолько абстрактными, насколько возможно;
- Методы должны компоноваться настолько, насколько возможно
про тотал: если его делать сценарием, то нужно в dsl делать ряд геттеров, а есть такое мнение, что геттеры и сетеры - ересь, поэтому total может уехать в api
Alexander
В clojure есть прекрасный принцип, примерно такой:
- First, program with data
- Second, program with functions
Alexander
То есть, если можно - программируем данными
Alexander
Если нет - функциями
Dmitry
@kana_sama а еще есть мнение, что если этот инвойс - просто ADT, то всё это достигается без применения клеточек из буллшит бинго, а просто обходом этого ADT
Denis
правда в кложе это превращается в жонглирование хешмапами
Alexander
про тотал: если его делать сценарием, то нужно в dsl делать ряд геттеров, а есть такое мнение, что геттеры и сетеры - ересь, поэтому total может уехать в api
Каких геттеров? Дергание методов, обращающихся за инвойсами в сервис - не есть геттер. Такой метод вернет просто ADT Invoice, и все данные доступны
Alexander
Нету никаких геттеров в смысле ООП
Dmitry
сеттеры. геттеры
Alexander
правда в кложе это превращается в жонглирование хешмапами
Да, но не единственная реализация принципа
Dmitry
я точно всё еще в чате про хаскель?
кана
ну окей, пусть total считается с неким коэфицентом, который зависит от интерпретатора
Alexander
Нету никаких геттеров и сеттеров.
Но в Haskell как таковом они есть в виде линз
кана
в total у нас будет геттинг этого коэфицента из api
Dmitry
линзы это просто сахар
Alexander
ну окей, пусть total считается с неким коэфицентом, который зависит от интерпретатора
Э-э, нет, вот еще одно правило для интерпретатора:
- в интерпретаторе не должно быть бизнес-логики
Dmitry
окей. но неважно, есть он или нет
Dmitry
наличие линз или их отсутствие ничего не изменит.
Denis
вы хоть сами понимаете о чем говорите?
Dmitry
кто именно?
Dmitry
я уже потерялся
Denis
да все
Dmitry
т.е мы поговорили за фримонады, и я понял, что можно не писать инстанс монады, если хочпется написать примерно столько же по объему чего-то иного
Dmitry
и еще получить ряд ограничений за это.
Alexander
в total у нас будет геттинг этого коэфицента из api
Если какой-то коэффициент есть в сервисе, и его можно достать методом сервиса, то это не "геттер". Это просто данные, которые вы получаете в сценарии. Да, в некотором роде, сценарии для invoice - императивны. Но только в некотором. И это необязательное правило для eDSL.
Denis
самая мякотка началась, когда тут за солид начали топить
Dmitry
мы поговорили за IoC и пришли к тому, что это фабрика, которая возвращает разные реализации в зависимости от состояния жирного xml-ного конфига, и при некотором напряге это делается и в нашем уютненьком.
Alexander
Денис, в чем проблема с SOLID?
Dmitry
хотя это бывает довольно непросто и код выгядит довольно неестественно при этом, да.
Denis
нет SOLID, нет проблем
Dmitry
особенно весело выглядит O и ADT, например
Alexander
Нет, ребята, вы так и не поняли. Вы оцениваете с позиции ООП. Вместо того чтобы понять, что есть универсальные принципы дизайна поддерживаемого, тестируемого, чистого кода. Не важно в какой парадигме.
Dmitry
мы сразу приезжаем к тайпклассам, тайпфэмили и вот этому вот всему
Denis
Проблема в том что про эту дурь для запугивания java-юниоров вообще думать не надо при написании функционального кода. В любых количествах.
Dmitry
UndeicidableInstances ftw
Alexander
Ну о чем тут можно говорить. Я пошел работать.
Alexander
Денис, не буду оспаривать ваше право на любую точку зрения, пусть даже неверную
Denis
передайте вашему работателю, что может отблагорить меня биткоинами, за возвращение сотрудника в работу
Dmitry
L в SOLID это вообще очень интересно. там звучит слово "correctness"
Dmitry
и угадайте что?
Dmitry
с I никто не будет спорить, но это просто тайпклассы, например. или функции.
Dmitry
я сделаю четвертый заход на фримонады, но если опять придется их выкинуть ввиду никчемности, прокляну.
Denis
L про сабтайпинг же
Dmitry
мне кажется это можно без сабтайпинга попробовать, но что насчёт корректности:
Dmitry
корректность это вообще что?
Dmitry
если мы не знаем, что с корректностью было до замены на сабтип
Dmitry
не знаем что было после
Denis
а покажи формулировку?
Dmitry
Denis
я пишу с утюга
Denis
спасибо
Dmitry
Dmitry
Liskov substitution principle[6]
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
Dmitry
если мы не знаем ничего о корректности того, что было
Dmitry
не знаем, какие изменения и побочные эффекты мы вносим, заменяя на другие инстансы, что мы можем сказать о корректности?
Dmitry
ничего не могли сказать до, ничего не можем сказать после
Denis
SOLID это как REST
Denis
из той же оперы
Dmitry
мне кажется это как BS
Denis
я разве не так сказал?
Dmitry
ну я сказал это короче
Dmitry
короче - значит, правильнее
Denis
засчитано
Dmitry
!
Dmitry
это мы, кстати, еще про большие программы vs маленькие не поговорили еще
Dmitry
например, что 10K loc на сях - это ниочём
Dmitry
а на 10K loc на хаскелле - это ничего себе.
Denis
я сегодня ретвитил про 200KLOC эльма в год
Dmitry
и о клеточках из BS бинго, как о способе сделать из маленькой программы большую, что бы решить проблемы программы, когда она станет большой
Denis
https://pbs.twimg.com/media/CxzX0scXUAA21uo.jpg