Comments 19
А что автор думает о Конструкторе по умолчанию у билдера?
О каком билдере речь?
Некий класс, который строит какую-то сущность, обычно сложную. Но есть и другие варианты — StringBuilder в Java. Хотя в нём можно сказать про то, что он инициализирует непротиворечивое состояние.
Тогда скорее стоит говорить о том, что если у нас есть класс с n полями, например Settings и ещё один класс SettingsBuilder, который
Работает так: new SettingsBuilder().setA(a).setB(b).setC©.build(). И вот метод build возвращает нам собранный экземпляр Settings, или, если мы в билдере вставили что-то не то или что-не не вставили — прилетит ошибка.
Тогда скорее стоит говорить о том, что если у нас есть класс с n полями, например Settings и ещё один класс SettingsBuilder, который
Работает так: new SettingsBuilder().setA(a).setB(b).setC©.build(). И вот метод build возвращает нам собранный экземпляр Settings, или, если мы в билдере вставили что-то не то или что-не не вставили — прилетит ошибка.
Моё личное мнение: вами приведённый билдер всё же лучше чем ничего, ибо теперь пользователь, хотя бы знает, что стоит обратить внимание на этап конструирования объекта, однако, чем ваш вариант для пользователя проще? Если и А и B и C являются необходимыми, то как узнать об этом пользователю? Почему бы не затребовать их в конструкторе?
Ну например потому, что конфигураций может быть много и разных. При наличии A обязательно наличие B и запрещено наличие C.
Собственно, вики расскажет лучше меня
Собственно, вики расскажет лучше меня
А еще есть такое слово DTO, Вообще, автор находит крайние слцчаи постоянно и начинает в них копаться.
А он и не говорит, что не должно быть конструкторов по умолчанию. Как говорит автор, эта серия — об ООП. DTO — не являются объектами, об этом эта статья из этой же серии.
Я дико извиняюсь, но у этого автора ООП головного мозга в критической стадии. Абстрактные идеи безопасной модели классов для него важнее соображений легкости проектирования, надежности, читабельности и обслуживаемости кода. Вакуумный ботан копается в пестиках и тычинках. И это не то же самое что освоить базовые правила, что бы потом перейти к нужным вещам, он совершенно не пытается осознать какая цель и стратегия у программирования в целом. У него на выходе всегда абсолютно правильный и на столько же абсолютно бесполезный и ненужный ответ.
Автор работал в Майкрософт, вообще известный программист и спикер. Не исключаю того, что он не «лучший» программист в мире (хм, а такой бывает?), но он явно не дурак.
Хорошее программирование приводит абстрактные идеи безопасных классов к вполне конкретным хорошим реализациям. Да, это не всегда возможно, но к этому нужно стремиться. И такой код поддерживать проще, чем кусок говна в одном классе, но зато умирающий при любом некорректном вводе, или кидающий исключения в неожиданных местах.
Хорошее программирование приводит абстрактные идеи безопасных классов к вполне конкретным хорошим реализациям. Да, это не всегда возможно, но к этому нужно стремиться. И такой код поддерживать проще, чем кусок говна в одном классе, но зато умирающий при любом некорректном вводе, или кидающий исключения в неожиданных местах.
Автор работал в Майкрософт
О, мощный аргумент однако. Вы так говорите как будто бы это хорошо. Все чего они достигли с этим подходом, это 5-10 кратный овехед во всем, финансировании, объеме кода, а на выходе мы получаем что-нибудь вроде IE и необходимость покупать технологии и приглашать специалистов со стороны.
Знал, что вы продолжите гнуть именно эту линию. Удачи, тролль.
У меня четкое мнение по этому вопросу и я могу аргументировать свою позицию. А вы мне ответили в духе авторитетствования, никаких аргументов. И после этого обозвать меня троллем, это, хм, не мудро.
Вы ответили на часть, посвящённую экспертократии. Остальную часть проигнорировали. Это, кхм, не мудро.
Я ответил на оба ваших абзаца, читать нужно. Вы написали поддерживать проще, я вам ответил — инварианты порождают кратный оверхед, а это поддерживать совсем не просто и экспоненциальный рост сложности тестирования.
У автора нет логических обоснований выбранной стратегии, а у меня есть серъезные примеры и причины сильно сомневаться в этой стратегии. А где ваши «вполне конкретные хорошие реализации»?
У автора нет логических обоснований выбранной стратегии, а у меня есть серъезные примеры и причины сильно сомневаться в этой стратегии. А где ваши «вполне конкретные хорошие реализации»?
Поддержка инвариантов — обязанность программиста. Тот кто избегает их защиты при такой возможности в угоду простоте, нуждается в ударе палкой по голове. С чего вдруг произойдёт рост сложности тестирования? Если вы используете TDD, как автор, то никакого роста сложности тестирования происходить не будет. Ну а при наличии нормальных инструментов, типа R#, мне смешно слышать про тягости поддержки разнообразных паттернов. Так любой паттерн можно подписать под кратный оверхед, может если программисту трудно понять такие элементарные конструкции, ему стоит выпить риталина?
Что я слышу что вы используете TDD и у вас не происходит роста сложности тестирования при росте количества инвариантов, может быть это вы чего-то не понимаете в TDD? Количество инвариантов растет, количество тестов не увеличивается, вам это совсем-совсем не кажется подозрительным? Вы ничего не замечаете?
И вообще, что это за намеки про удар палкой по голове, риталин? Вам сколько лет вообще? При встрече в реале думаю такие фантазии у вас прекратились бы мгновенно.
И вообще, что это за намеки про удар палкой по голове, риталин? Вам сколько лет вообще? При встрече в реале думаю такие фантазии у вас прекратились бы мгновенно.
Про удар палкой по голове и риталин — абсолютно нормально. Мы так разговариваем на работе, шутка-шуткой.
Практикуя TDD вы придёте к нормальной реализации с защищёнными инвариантами, вот я о чём. Всё сложится «само собой».
С трудом верится в то, что простота перекроет потенциальные баги из-за отказа от защиты инвариантов. Либо, если вы пишите открытое API — перекроет ненависть всех пользователей, которые не обязаны рыться в дебрях ваших внутренних реализаций и догадываться, что вы там имели ввиду.
Практикуя TDD вы придёте к нормальной реализации с защищёнными инвариантами, вот я о чём. Всё сложится «само собой».
С трудом верится в то, что простота перекроет потенциальные баги из-за отказа от защиты инвариантов. Либо, если вы пишите открытое API — перекроет ненависть всех пользователей, которые не обязаны рыться в дебрях ваших внутренних реализаций и догадываться, что вы там имели ввиду.
Мы уходим от моего исходного тезиса. Надеюсь вы на досуге подумаете над моими вопросами почему у вас при росте количества инвариантов не растет сложность тестирования и поймете наконец, что TDD процесс не полный. И всё сложится «само собой» это как-то очень уж легкомысленно звучит в виду этого.
Отказ от защиты данных в большинстве случаев все-таки приводит к уменьшению количества багов, не всё мы пишем публичное API и не работаем в команде мартышек или вредителей, а совокупное уменьшение сложности и дает в конечном итоге уменьшение бажности.
Отказ от защиты данных в большинстве случаев все-таки приводит к уменьшению количества багов, не всё мы пишем публичное API и не работаем в команде мартышек или вредителей, а совокупное уменьшение сложности и дает в конечном итоге уменьшение бажности.
TDD — полный процесс. По крайней мере, если вы его практикуете как авторы этой книги. Если вы её читали, то, кстати, интересно ваше мнение по этому поводу.
Следование принципам TDD, прислушивание к тестам, реализация End-to-End тестирования через UI-тесты фич, построение walking skeleton приводит к построениею Hexagonal архитектуры (a.k.a. Ports and Adapters by Alistair Cockburn), в которой инъекция зависимостей через конструктор, защита инвариантов получаются «сами собой». Понятно, что «сами собой» это несколько неправдиво, но для этого и есть процесс со своими правилами выращивания ПО.
Следование принципам TDD, прислушивание к тестам, реализация End-to-End тестирования через UI-тесты фич, построение walking skeleton приводит к построениею Hexagonal архитектуры (a.k.a. Ports and Adapters by Alistair Cockburn), в которой инъекция зависимостей через конструктор, защита инвариантов получаются «сами собой». Понятно, что «сами собой» это несколько неправдиво, но для этого и есть процесс со своими правилами выращивания ПО.
Sign up to leave a comment.
«Запах» проектирования: конструктор по умолчанию