И если это банальные вещи, то можно посмотреть на Ваш код, где все эти вещи реализованы?
вы этого не увидите, потому что я не согласен с вами полностью ни по одному из этих пунктов.
Более менее я стараюсь избавляться от проверок аргументов на null, это решается при помощи code contracts. null как результата функции тоже надо избегать, но все хорошо в меру.
Синглтон решается любым DI фреймворком. И то, пока проект маленький я даже и не подумаю что-то делать в этом направлении, у меня мало времени на перфекционизм
Immutable? все хорошо когда, у тебя value object, но как entity может быть immutable?
Можно увидеть, скажем, 5000 строк Java кода без NULL?
ну если бы вы читали мои комментарии, то знали бы что я пишу не на яве )) а в дотнете с этим попроще
Вообщем заголовок меня заинтриговал, а в этом увлекательном разговоре нет возможности ознакомиться с позицией
Егора, потому что тут больше про борьбу с оппонентами, чем про ООП. Возможности купить книгу в электронном варианте тоже нет,
поэтому пришлось собирать целостную картинку из записей в блоге, а не из книги.
Итак нам обещают ООП 2.0
1) Why NULL is Bad?
«null плохой». ок, но мы это уже давно знаем. эта тема обсосана со всех сторон.
5) Objects Should Be Immutable
«all classes should be immutable in a perfect object-oriented world». эта тема обсосана со всех сторон.
6) OOP Alternative to Utility Classes
«Utility классы зло, каждому методу по обьекту». И такой код я тоже видел.
аргументы: SRP, удобнее писать тесты, «An object-oriented approach enables lazy execution». весьма слабо.
7) If-Then-Else Is a Code Smell
if — зло, vrtual dispatch — добро. где-то я это уже видел. может у Фаулера/Физерса/Кириевски?
основной посыл в этих двух примерах, как я понял, что в первом случае мы получаем DTO из api и чего-то там с ним делаем, а во втором у нас уже появляется entity, которая обладает поведением и всем таким, что присуще rich model. Нууу… как бы да, хорошо, а где ООП v2?
и как то там весьма, кхм, как бы это сказать. Вообщем-то все то же, что можно увидеть в книжках критикуемого фаулера ))
И очевидно предлагается научить обьект загружаться/сохраняться в базу/json/… минуя DTO
я прочел первую статью про null из 2014 года, и я слабо понимаю чего это народ так наиндуцировался. По сути расписаны весьма очевидные вещи. Я не знаю как там в Java мире, но у нас в .net вещи примерно так и обстоят.
BTW, оттуда же из статьи
Iterator found = Map.search("Jeffrey");
if (!found.hasNext()) {
throw new EmployeeNotFoundException();
}
return found.next();
имхо под этим куском кода маскируется желание использовать некий Optional<>, просто автор еще сам этого не понял ))
тем не менее команда нисколько не пострадала, а решение не было бездумным, мы просто выкинули раздражающий и отвлекающий фактор. каждый день мы были вынуждены слушать все, что и так знали. кстати ретроспектива отправилась в ту же топку. скрам ли это после таких изменений? я не знаю, но хуже точно не стало.
>бездумно
бездумно вообще ничего делать нельзя ))
>Правила скрама более продуманны, чем может показаться на первый взгляд.
я знаю насоклько они продуманы, у меня была возможность увидеть как работает та или иная вещь в других командах, и все же посмею утверждать, что они не универсальны, иначе это превращается в серебряную пулю
>Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».
А у меня команде не было DSM, и была отличная «синхронизация». Когда у тебя в команде 3 человека и один QA которые в постоянном контакте, а не одни социопаты, то все отлично.
А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплывет
серьезно, вы правда думаете, что все будут делать так
?
вы этого не увидите, потому что я не согласен с вами полностью ни по одному из этих пунктов.
Более менее я стараюсь избавляться от проверок аргументов на null, это решается при помощи code contracts. null как результата функции тоже надо избегать, но все хорошо в меру.
Синглтон решается любым DI фреймворком. И то, пока проект маленький я даже и не подумаю что-то делать в этом направлении, у меня мало времени на перфекционизм
Immutable? все хорошо когда, у тебя value object, но как entity может быть immutable?
ну если бы вы читали мои комментарии, то знали бы что я пишу не на яве )) а в дотнете с этим попроще
Егора, потому что тут больше про борьбу с оппонентами, чем про ООП. Возможности купить книгу в электронном варианте тоже нет,
поэтому пришлось собирать целостную картинку из записей в блоге, а не из книги.
Итак нам обещают ООП 2.0
1) Why NULL is Bad?
«null плохой». ок, но мы это уже давно знаем. эта тема обсосана со всех сторон.
2) Getters/Setters. Evil. Period.
«get/set плохо». суть статьи — вместо процедурного барахла, используйте ООП
3) Data Transfer Object Is a Shame
«DTO плохо» взамен предлагается переложить сериализацию/десериализацию на саму сущность, минуя DTO
4) ORM Is an Offensive Anti-Pattern
«ORM плохо» взамен предлагается active record и репозитарий для бедных
5) Objects Should Be Immutable
«all classes should be immutable in a perfect object-oriented world». эта тема обсосана со всех сторон.
6) OOP Alternative to Utility Classes
«Utility классы зло, каждому методу по обьекту». И такой код я тоже видел.
аргументы: SRP, удобнее писать тесты, «An object-oriented approach enables lazy execution». весьма слабо.
7) If-Then-Else Is a Code Smell
if — зло, vrtual dispatch — добро. где-то я это уже видел. может у Фаулера/Физерса/Кириевски?
8) Singletons Must Die
синглтоны зло.
9) Class Casting Is a Discriminating Anti-Pattern
cast зло
10) Composable Decorators vs. Imperative Utility Methods
Why Many Return Statements Are a Bad Idea in OOP
Разложим мир на микроскопические обьеты.
Итого: Либо банальные вещи, либо маргинальные экстремистские идеи. Так мы будем писать через 20 лет?
ORM низя — http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html
И очевидно предлагается научить обьект загружаться/сохраняться в базу/json/… минуя DTO
Чем это отличается от rich model? переименовали сеттеры? А что нам делать с DTO?
BTW, оттуда же из статьи
имхо под этим куском кода маскируется желание использовать некий Optional<>, просто автор еще сам этого не понял ))
а что это не так?
>бездумно
бездумно вообще ничего делать нельзя ))
>Правила скрама более продуманны, чем может показаться на первый взгляд.
я знаю насоклько они продуманы, у меня была возможность увидеть как работает та или иная вещь в других командах, и все же посмею утверждать, что они не универсальны, иначе это превращается в серебряную пулю
>Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».
вообще примерно так и было ))
А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплывет
Моя success story — я уехал из Ростова