А если вы сильно волнуетесь насчёт того, что вот именно завтра-послезавтра обрушится вся мировая финансовая система? Что вы будете делать, если у вас полтора миллиона рублей?
Я имел ввиду, что при коллапсе всей мировой финансовой системы, вы останетесь с автомобилем и гаражом, а не с голой жопой, которая у вас обязательно образуется, в результате хранения денег в банке.
Я не знаю хорошего способа накопления (хранения, вложения) средств при накоплении на квартиру. Но, если у вас, например, миллиона полтора и вы не копите на квартиру, то, при наличии страхов потери и этих средств (тоже немалых), можно купить гараж и машину.
А вот авторы Growing Object Oriented Software Guided by Tests рекомендует сразу же создавать классы, при малейшем намёке на отдельную сущность, даже если там будет на первых порах один метод. Как правило боязнь создания «лишних» классов это какая-то дедовская болезнь, проистекающая от полного непонимания SOLID и ООП вообще. И да, с таким подходом никогда не возникает сотен классов с одним методом внутри. Навигация никогда не становится хуже.
Насчёт методов из трёх строк. Всегда (почти) предпочту метод из трёх строк методу из 20. Чаще всего, когда ты читаешь чей-то код, ты пытаешься понять смысл того, что делает этот код, а не детализированную имплементацию, поэтому, если программист писал множество мелких функций, то функции верхнего уровня читаются действительно как «хорошо написанная проза», а если нужны детали — всегда можно заглянуть в детали. Не надо меня кормить деталями, если я вас об этом не просил, я хочу иметь выбор: просто понять быстро смысл написанного или спуститься для изучения деталей.
Катастрофа может произойти по любой причине, но, как утверждают авторы, в данном случае причина была именно в этом. А мы стараемся же избегать катастроф, да? А про излишние накладные расходы, исключая того, что вам уже сказали относительно С++, какие накладные расходы больше — лишний вызов или пара миллиардов долларов в случае катастрофы? (с учётом пункта — делайте абстракции для концепций, а не используйте примитивы)
p.s. Промазал уровнем, извиняюсь, утро — не проснулся ещё)))
Недавно прочиталал в «Growing object oriented software guided by tests» про случай, когда NASA, разрабатывавшая программу для какого-то комического изделия, который должен был лететь на Марс, пострадали как раз из-за того, что хранили различные метрики, отличающиеся по смыслу в примитивах (числовых). Кто-то где-то спутал концепции и в результате произошла «катастрофа». Авторы рекомендует выделять концепции в отдельные классы в любом случае, даже если там проверок никаких не будет. Имя класса или структуры делает акцент на том, что есть некая сущность, представляющая концепт.
Вот один из комментариев самого автора к данному посту в его же блоге:
Я согласен с тем, что когда речь заходит о валидации входных данных от пользователя, использование атрибута на одном или более свойств с очень рыхлой поддержкой инвариантов это лучшее решение. В целом, на границах приложения, всегда лучше предполагать, что ввод может быть некорректен и введён как угодно. Это также справедливо как для UI-ввода, так и автоматического ввода (XML, CSV, JSON и т.д.). Таким образом, любой «объект», моделирующий структуру данных на границе приложения не является инкапсулированным.
Однако, было бы непростительной ошибкой, если бы мы позволили пользовательскому интерфейсу направлять проектирование наших доменных моделей. Таким образом, как только мы знаем, что у нас случай с корректными входными данными, мы должны транслировать его в правильно инкапсулированный объект. С этой точки зрения (включая дизайн схемы БД), атрибут оказывается абсолютно излишним.
Кстати, да, я не вчитался в подробности того твита. Возможно, я выбрал неудачный пример. Я не ставил себе целью разносить Entity Framework. Всё, что я до сих пор слышал о NHibernate говорит мне о том, что он имеет те же проблемы относительно инкапсуляции.
TDD — полный процесс. По крайней мере, если вы его практикуете как авторы этой книги. Если вы её читали, то, кстати, интересно ваше мнение по этому поводу.
Следование принципам TDD, прислушивание к тестам, реализация End-to-End тестирования через UI-тесты фич, построение walking skeleton приводит к построениею Hexagonal архитектуры (a.k.a. Ports and Adapters by Alistair Cockburn), в которой инъекция зависимостей через конструктор, защита инвариантов получаются «сами собой». Понятно, что «сами собой» это несколько неправдиво, но для этого и есть процесс со своими правилами выращивания ПО.
Про удар палкой по голове и риталин — абсолютно нормально. Мы так разговариваем на работе, шутка-шуткой.
Практикуя TDD вы придёте к нормальной реализации с защищёнными инвариантами, вот я о чём. Всё сложится «само собой».
С трудом верится в то, что простота перекроет потенциальные баги из-за отказа от защиты инвариантов. Либо, если вы пишите открытое API — перекроет ненависть всех пользователей, которые не обязаны рыться в дебрях ваших внутренних реализаций и догадываться, что вы там имели ввиду.
Поддержка инвариантов — обязанность программиста. Тот кто избегает их защиты при такой возможности в угоду простоте, нуждается в ударе палкой по голове. С чего вдруг произойдёт рост сложности тестирования? Если вы используете TDD, как автор, то никакого роста сложности тестирования происходить не будет. Ну а при наличии нормальных инструментов, типа R#, мне смешно слышать про тягости поддержки разнообразных паттернов. Так любой паттерн можно подписать под кратный оверхед, может если программисту трудно понять такие элементарные конструкции, ему стоит выпить риталина?
Моё личное мнение: вами приведённый билдер всё же лучше чем ничего, ибо теперь пользователь, хотя бы знает, что стоит обратить внимание на этап конструирования объекта, однако, чем ваш вариант для пользователя проще? Если и А и B и C являются необходимыми, то как узнать об этом пользователю? Почему бы не затребовать их в конструкторе?
Автор работал в Майкрософт, вообще известный программист и спикер. Не исключаю того, что он не «лучший» программист в мире (хм, а такой бывает?), но он явно не дурак.
Хорошее программирование приводит абстрактные идеи безопасных классов к вполне конкретным хорошим реализациям. Да, это не всегда возможно, но к этому нужно стремиться. И такой код поддерживать проще, чем кусок говна в одном классе, но зато умирающий при любом некорректном вводе, или кидающий исключения в неожиданных местах.
А он и не говорит, что не должно быть конструкторов по умолчанию. Как говорит автор, эта серия — об ООП. DTO — не являются объектами, об этом эта статья из этой же серии.
Ну и зря минусуете. Я хотел сохранить структуру статей. Залил первую — она ведёт на 5 других. Я хотел быстрее залить остальные, чтобы меня не слили за перевод отправной статьи (или одной отрывочной). Делать пришлось быстро. Какой-то косяк получился с одной из статей. Получился дубль. Пришлось одну убирать, потом другую добавлять. Это не жалоба, то, что это проблемно — это факт)))
Насчёт методов из трёх строк. Всегда (почти) предпочту метод из трёх строк методу из 20. Чаще всего, когда ты читаешь чей-то код, ты пытаешься понять смысл того, что делает этот код, а не детализированную имплементацию, поэтому, если программист писал множество мелких функций, то функции верхнего уровня читаются действительно как «хорошо написанная проза», а если нужны детали — всегда можно заглянуть в детали. Не надо меня кормить деталями, если я вас об этом не просил, я хочу иметь выбор: просто понять быстро смысл написанного или спуститься для изучения деталей.
p.s. Промазал уровнем, извиняюсь, утро — не проснулся ещё)))
Я согласен с тем, что когда речь заходит о валидации входных данных от пользователя, использование атрибута на одном или более свойств с очень рыхлой поддержкой инвариантов это лучшее решение. В целом, на границах приложения, всегда лучше предполагать, что ввод может быть некорректен и введён как угодно. Это также справедливо как для UI-ввода, так и автоматического ввода (XML, CSV, JSON и т.д.). Таким образом, любой «объект», моделирующий структуру данных на границе приложения не является инкапсулированным.
Однако, было бы непростительной ошибкой, если бы мы позволили пользовательскому интерфейсу направлять проектирование наших доменных моделей. Таким образом, как только мы знаем, что у нас случай с корректными входными данными, мы должны транслировать его в правильно инкапсулированный объект. С этой точки зрения (включая дизайн схемы БД), атрибут оказывается абсолютно излишним.
Кстати, да, я не вчитался в подробности того твита. Возможно, я выбрал неудачный пример. Я не ставил себе целью разносить Entity Framework. Всё, что я до сих пор слышал о NHibernate говорит мне о том, что он имеет те же проблемы относительно инкапсуляции.
Следование принципам TDD, прислушивание к тестам, реализация End-to-End тестирования через UI-тесты фич, построение walking skeleton приводит к построениею Hexagonal архитектуры (a.k.a. Ports and Adapters by Alistair Cockburn), в которой инъекция зависимостей через конструктор, защита инвариантов получаются «сами собой». Понятно, что «сами собой» это несколько неправдиво, но для этого и есть процесс со своими правилами выращивания ПО.
Практикуя TDD вы придёте к нормальной реализации с защищёнными инвариантами, вот я о чём. Всё сложится «само собой».
С трудом верится в то, что простота перекроет потенциальные баги из-за отказа от защиты инвариантов. Либо, если вы пишите открытое API — перекроет ненависть всех пользователей, которые не обязаны рыться в дебрях ваших внутренних реализаций и догадываться, что вы там имели ввиду.
Хорошее программирование приводит абстрактные идеи безопасных классов к вполне конкретным хорошим реализациям. Да, это не всегда возможно, но к этому нужно стремиться. И такой код поддерживать проще, чем кусок говна в одном классе, но зато умирающий при любом некорректном вводе, или кидающий исключения в неожиданных местах.
Нельзя так ни к кому относиться. Будьте добрее.