Очередное выдёргивание, переворачивание, повторение одних тех же уже множество раз опровергнутых тезиов. На этом всё. Удачи вам в вашем нелёгком труде, который вы успешно делаете ещё более тяжёлым.
Может быть вы такие приложения не пишете, и для вас такие требования это фантазии.
Пишу. И если бы вы только захотели, вы бы поняли, что “фантазиями” я называю преждевременные и необоснованные предположения о том, как система может развиваться в будущем. А не то, что было удобно увидеть вам.
У меня они встречаются в каждом приложении.
…И вы в каждом приложении дублируете их реализацию. Понимаю. Это делают (почти) все.
Поэтому для моих задач ваш метод не подходит. Почему? Потому что будет сложнее вносить новые изменения в код, и сложнее разбираться как он работает
Неверное утверждение, основанное на неверных посылках.
Надеюсь, вы не рассчитывали, что я буду вникать в перипетии вашей задачи? Уверен, что нет. Почти уверен, что это нужно лишь для того, чтобы в очередной раз сказать, что я "ухожу от темы". Что, кстати, тоже является ложным утверждением.
Но если всё же вдруг рассчитывали, то вынужден вас огорчить. Мне, очевидно, некогда разбираться в деталях ваших задач. Вам за них платят деньги, а не мне. А у меня свои задачи есть.
К тому же смысла в таких разбирательствах относительно изначально поднятой темы (sic! не темы решения ваших конкретных примеров-упражений, а темы про DRY) я не вижу.
Во-первых, как вы верно заметили, подобное происходит буквально в каждом проекте. И при этом есть люди, которые утверждают, что дублирование устранять необходимо. Значит, для них это работает.
Во-вторых, на любое предложенное решение конкретной задачи вы будете отвечать накидыванием новых задач по типу "а если пришёл менеджер/бизнес/кто-то и докинул требовний". Это бесконечный процесс, который хорошо позволяет только кидаться разными обвинениям в адрес оппонента, но ничего не даёт с точки зрения обоснования работоспособности подхода.
То, что я успел посмотреть — никаких особых проблем не представляет, всё вполне обыденно и решается в рамках стандартного итерацинного подхода к разработке сложных систем — небольшими шагами, чередующими добавление новой функциональности и рефакторинг. Последний — с тем самым устранением дублирования с целью упрощения системы, что позволяет упростить и добавление новой функциональности. И да, существующий код время от времени переписывается. В этом нет ничего страшного или плохого. Как раз наоборот — позволяет избежать создания необоснованно сложных "универсальных" решений на основе тех самых фантазий разработчиков.
В общем, этот "мой" (если бы это был действительно мой, я бы считал, что жизнь прожита не зря; но я, к сожалению не автор, а всего лишь пользователь) метод как раз обеспечивает и простоту внесения изменений в код (как раз за счёт устранения дублирования), и упрощает понимание (за счёт абстрагирования).
Очередной "уход от темы" завершён, на этом разрешите откланяться.
У меня возникло ощущение, что вы в ходе дискуссии упорно демонстрируете когнитивное искажение, называемое Confirmation Bias (не помню, как его назвали на русском), задавшись некоторым предположением, ищете в высказываниях собеседника то, что подтверждает его, и старательно игнорируете то, что может его опровергнуть.
Было несколько примеров. Если вы это делаете осознанно, тогда просто проигнорируйте это замечание — можно не доказывать, что это не так, я не настаиваю на истинности этого наблюдения.
Если же это делается не намеренно, то, проанализируйте — вдруг это подтвердиться, и вы захотите это исправить.
Я уже едва сдерживаюсь, но ладно, пока есть силы, продолжим эту игру :D
Category class >> from: categoryDto ^ self new name: categoryDto name. parentId: categoryDto parentId.
Product class >> from: productDto ^ self new name: productDto name; categoryId: productDto categoryId.
Вам именно этого не хватало для полного счастья?
Или нужно добавить, что если, например, делать раз за разом одно и то же (например, клепать админки), и он заметит, что создание админок — это на …(подставьте нужное значение)% и есть дублирование, и решит это дублирование вынести в отдельный фреймворк, то в нём появится примерно такой код:
…А Category, Product и все другие классы, в которых будет требоваться функциональность чтения из DTO, будут в этом фрейворке регистрироваться. И этот фрейворк будет в нужных точках с помощью DtoReader-а создавать их экземпляры? (Да, это был вопрос.)
Код этого фреймворка я приводить по понятным (тем, кто захочет понять) и даже очевидным причинам. Тем более, что при написании такого фрейворка в нормальной объектной среде в принципе не возникнет никакой необходимости в DTO.
…:Будет 11-е повторение? Если будет, вы уж уточните тех.задание. А то я спрашиваю-спрашиваю, реализацию какой именно функциональности и в каких именно рамках вы так жаждете увидеть, а вы всё игнорируете и игнорируете. Всё повторяете одно и то же, и повторяете. Я, вроде бы понимаю, а вы говорите, что нет. И опять повторяете то же самое.
Покажите код полностью, в том числе то, что у вас там переносит значения из DTO в модель, тогда я вам ткну пальцем где и при каких требованиях там будет сложность.
Гениально! Так вы собираетесь заставлять меня писать код до каких пор? До кода виртуалной машины? Или инструкций процессора? Может до схемы на платах компьютера и устройства процессра? Ведь на каждом этапе будет отсылка на что-то сложное, очень часто даже гораздо более сложное, чем исходная задача. Вы действительно не понимаете, что такое абстракция? Не понимаете разницу между essential complexity и accidental complexity? Не понимаете, что первую устранить можно, только изменив постановку задачи, и с ней приходится жить? Что эту сложность побороть можно (только?) методом "разделяй и властвуй"? Что суть ОО-дизайна состоит как в распределении сложности между объектами и затем их комбинации?
Ну, хорошо. Давайте ещё на одну ступеньку вниз спустимся. В текущем понимании, думаю, достаточно будет такой реализации:
Как пройтись переменным экземпляра DTO и передать их значение в конструктор модели, расписывать, надеюсь, не нужно?
Возможно, вы захотите придраться к "захардкоженому" в методе словарю. Но поверьте, я без проблем вынесу это дело, обеспечив инъекцию зависимостей. Например, через аннотации.
В очередной раз объяснять вам, что это всё в принципе нереалистично, наверное, бесполезно? Уверен, что да. Но вдруг это еще кто-то будет читать. Оставлю как примечание на такой случай.
Вы же опять скажете, что всю сложность "замёл под ковёр"? Хотя, по факту, это и есть абстракция через распределение ответственности между объектами. Там придётся подтягивать ещё и обсуждение "анемичные модели (по факту процедурное программирование) против ООП (это я вам в самом начале писал, вот оно — вылезает потихоньку).
Вся наша перепалка уже давно свелась к вопросам о том, что понимать под "дублированием" и любое ли "дублирование" можно устранить, упростив при этом систему", а так же"что хотел сказать автор?".
Первые два просто не помещаются в формат комментариев.
А по последнему — это про
Выглядит так, что вы считаете, что собеседники считают, что DRY применять вообще никогда не надо, и пытаетесь доказать, что надо.
Если не вдаваться в детали, примерно так и есть.
Автор статьи, даже если хотел сказать что-то другое, явно и однозначно предложил отказаться от DRY. Других вариантов трактовки смысла написанного под заголовком (которого, в принципе уже достаточно) "Да, пожалуйста, повторяйтесь" я при всём желании найти не могу. Хотя честно пытался (ещё до того, как меня таки угораздило втянуться в эту перепалку). Но получилось сгенерировать лишь две версии такого “совмещения”:
В одних случаях не повторяемся, в других повторяемся. В этой идее, кстати (как я раньше уже писал) в нет ничего нового, она изначально заложена в идее “устраняем дублирование”, так как хочешь-не хочешь, но сначала придётся определиться, что понимать под дублирование. Очевидно же, — и про это я тоже уже писал — что, например, устранять дублирование отдельных символов в коде не имеет смысла. Но у автора статьи про это нет ни слова — не то, что про определение понятия “дублирование” или критерий применимости DRY, даже про саму возможность такого выбора. То ест, здесь просто предлагается заменить DRY на PRY. Я где-то здесь ошибаюсь?
Двоемыслие. Этот вариант вряд ли заслуживает подробного рассмотрения — не так ли?
Автор комментария, который послужил непосредственным поводом к этой дискуссии, особых возражений к изложенному в статье или новых трактовок не выдвинул, но косвенно — поделившись своим опытом — вроде как предложил некий критерий в русле п.1. Именно так я понял изначально его мысль и именно поэтому попросил примеры. Какие именно примеры могли бы подтвердить данный подход— см. мои предыдущие сообщения. Это не те примеры, которые вы привели.
Почему же я приравниваю изложенную в том комментарии точку зрения к призыву отказа от DRY? По той же причине — отсутствия чёткого критерия применимости этого принципа. Конкретно, что предлагает автор комментария:
Мне нравится делить приложение на очень слабо связанные слои (или даже пакеты) /…/ Однако, если какая-то "общая" на первый взгляд функциональность появляется в разных пакетах, то я буду 100500 раз думать перед тем, как выносить это всё в абстракцию. Иначе это может стать большой головной болью.
То есть, предлагается устранять дублирование только внутри отдельного “пакета”, который кто-то когда-то по каким-то причинам решил выделить. Это, конечно, не такой категорический отказ, какой предлагается в статье, но тем не менее именно отказ, так как “100500” представляет собой практически синоним слова “бесконечность”, В купе с неясными критериями деления по пакетам такой подход делают критерий применимости DRY абсолютно размытым и, по сути, даёт зеленый свет к тому же самому отказу от DRY по принципу "Не знаешь, как устранить дублирование? Просто забей!"
Кроме того, в этом комментарии содержится серьезный логический изъян (или когнитивное искажение) — на что я тоже ранее уже указывал (как же часто мне приходится повторять то, что я ранее всё это уже излагал!):
По поводу DRY. Очень часто сталкивался с тем, что изначально невинные абстракции потом разрастались до каких-то монстров с таким ветвлением, что уследить за ним могли не только лишь все.
Между "устранением дублирования" и "превращением абстракции в монстра" здесь нет причинно-следственной связи. Устранение DRY — это рефакторинг, который должен упрощать систему, так дублирование — это как раз усложнение.
Итог: оба автора предлагают в той или иной степени ограничить использование DRY. Один — радикально, другой — через неясные, размытые критерии.
Возможно, и эти авторы, и вы пытались сказать что-то другое? Возможно. Но в таком случае это просто не удалось сделать. Разумеется, с моей — субъективной и не претендующей на окончательную истинность — точки зрения.
P.S.: Да, опять получилось много букв (и это только мЕньшая часть из уже написанных) и мало кода. Но это не потому, что, (как вам явно хочется думать) я не умею его писать или редко это делаю или пишу "игрушечный" код. Это не так. Просто вы сами задали такие условия "игры" …что — уже надоело, но я ещё раз это отмечу — я уже не раз здесь заявлял.
Да, я решил, что вам это интересно, так как вы систематически игнорировали все мои попытки прекратить эту (как мне на тот момент казалось) бессмысленную дискуссию, и, напротив, всячески её поддерживали. А когда я всё-таки увидел хоть какой-то смысл, вы тут же заявили, что вам не интересно. Ну, хорошо. Дело хозяйское :)
Извините, конечно :) но я буду делать то, что интересно и нужно мне. То, что вас интересует, "меня интересует меньше. Интересует. Но меньше." (с)
У меня нет цели убедить лично вас в чём-то или победить в это "споре". За 25 лет в программировании я принял участие в разработке довольно большого количества проектов. По крайней мере, достаточное для того, чтобы сформировать своё понимание, много раз уточнить/скорректировать и проверить его. Данная дискуссия навела меня на некоторые мысли и даже, в конечном счёте, на очередные корректировки. Ими я и собираюсь поделиться. Но удовлетворение ваших запросов — это ваше собственное дело.
Я не слился ;) Отвечу позже (когда будет время) и, скорее всего, не здесь — в рамках комментариев уже стало совсем тесно. Ссылку, разумеется, сюда скину.
Правильно. Теперь откройте текст статьи и прочитайте, что там написано по поводу DRY.
Теперь откройте мой комментарий и прочитайте, что там написано. Соотнесите. Подумайте. Попробуйте понять. Я ещё долго могу продолжать, но, может, всё-таки откажемся от императивного стиля? ;)
Вот разговор как раз и был о том, что таких ситуаций много, и люди часто пытаются убрать дублирование там, где это не нужно.
Неправильно. Теперь откройте текст статьи и комментариев и прочитайте, что там написано.
Именно об этом сказали автор статьи, автор начального комментария, и я. Поэтому я не понимаю, с чем вы спорите.
У вас наблюдается удивительная "сверх"-способность видеть и понимать то, что не было написано, и не понимать то, что написано :)
Без особой надежды на понимание постараюсь еще раз — максимально просто и кратко…
========================= Начало пояснения
В статье предлагается следующая логика (это не цитата, просто других способов выделить текст не нахожу):
У меня не получается применять принцип DRY, следовательно он плохой. Его использовать не надо, это даже почти грехом объявляется :) И предлагается заменить на PRY.
Это на столько дико, что спорить с этим я вообще не вижу смысла. От короткого комментария по этому поводу не удержался, но на этом всё.
А вот с комментарием, на который я ответил, я вообще не спорил. Где вы это вообще обнаружили? …А, ну да — сверх-способности же ;) Простите.
Я всего лишь попросил пример, когда появившиеся в результате адекватного применения DRY …
…изначально невинные абстракции потом разрастались до каких-то монстров с таким ветвлением, что уследить за ним могли не только лишь все.
В ответ на это вы привели абсолютно неадекватные примеры, на что я вам и указал. И тут понеслось… :D
Адекватным примером был бы:
Кусок функциональности, к которому имеет смысл применить DRY
Результат этого рефакторинга — "невинная абстракция"
Какой из этого в итоге получился монстр, и его связь с предыдущим рефакторингом
========================= Конец пояснения
А с чем я действительно готов спорить по поводу DRY, я подробно объяснил ранее. Но вы это проигнорировали, как это модно было говорить, "чуть более, чем полностью".
Вот в том и смысл этого примера, что можно. В них содержится столько информации, сколько есть на старте проекта.
Если действительно так, то это печально. Остаётся только пожалеть вас и всех, кто связан с подобными проектами. Но я всё же подозреваю, что вы утрируете. …Но этим, в общем-то, и ограничивается связь приведённого вами ужасающего факта с дискуссией по поводу DRY.
Это написано в первом комментарии, на который вы отвечали: "больше двух повторений - повод задуматься".
Да, согласен. Занесло :) Но если вы так и не поняли, то этот момент у меня возражений как раз не вызывал.
Что еще раз говорит о том, что вы не следите за дискуссией и спорите о чем-то своем.
У вас какие-то проблемы с логикой? То, что я повторил и более подробно раскрыл мысль, вскользь упомянутую выше и не имеющую прямого отношения к обсуждаемой проблеме, говорит именно об этом? Другие варианты исключены?
Нет, не должен.
Если вы не отвечаете нет, то это говорит о том, что ваши "примеры" неадекватны. Что я с самого начала до вас и пытался донести — об этом выше.
Остаётся только понять, вы эти привели по недоразумению или намеренно, для троллинга? Ну, чтобы завязать спор на пустом месте и всеми неправдами пытаться в нём победить. Ок, вы победили. На этом завершим? Я ниже только ещё отвечу на некоторые интересные моменты. Но можем считать, что на результат это не влияет — вы блистательно победили!
Это тоже говорит о том, что вы спорите о чем-то своем.
Это тоже говорит о том, что вы так и не поняли или не захотели понять смысл моего комментария.
Могли бы на любом языке написать. Но так обычно и получается в таких дискуссиях, умных слов много, а как код написать, то находятся всякие отговорки.
В моей системе на Smalltalk-е DTO скорее всего не было бы в принципе. Но если вам так хочется кода, пожалуйста:
EntityService >> createFrom: aDto model = mapper createModelFrom: aDto. entityManager save: model. ^ model
YAGNI Он говорит о том, что не надо добавлять функциональность, если она не нужна. И я как раз предлагаю ее не добавлять. Это вы предлагаете вместо уже написанного кода делать универсальный сохраняющий объект.
Вы предлагаете не добавлять новую функциональность, а не устранять дублирование — это рефакторинг, так как на существующую функциональность это действие как раз влиять не должно.
А делать это, точнее не делать, вы предлагаете из каких-то смутных фантазий о том, что когда-то в будущем это может привести к проблемам. Вот здесь и возникает You Are Not Gonna Need It — решать какие-то смутные будущие проблемы.
И ещё раз (вдруг всё-таки поймёте) обращу ваше внимание, что мой исходный вопрос как раз был про эти будущие проблемы.
Понятно, вместо 20 строк кода вы решили написать много текста.
Не, зачем 20? 4-х достаточно. Но Вам это сильно помогло? Возможно, для вас это станет сюрпризом, но смысл кода не всегда ясен из самого кода. Иногда нужен контекст. А это будет значительно больше 20 строк.
Видимо кода будет еще больше. Это хорошо показывает цену вашего подхода и правильность утверждения про монстра.
И у вас опять наблюдаются проблемы с логикой Ну, с трактовкой-анализом имеющихся фактов и выводами из них.
Только прошу понять правильно и не расценивать как переход на личности. Это просто к сомнениям о целесообразности продолжения этой перепалки. Получить нужные примеры надежду я уже давно потерял. Полезного спора как с самого начала не получалось, так до сих пор, к сожалению не намечается.
Хорошо, уговорили, потрачу ещё какую-то часть своего бесценного времени в надежде, что это кому-нибудь чем-нибудь поможет.
Это написано прямым текстом в первом комментария этой ветки
Читаем внимательно и не выдёргиваем из контекста. Комментарий начинается словами:
По поводу DRY.
Про что разговор? Про DRY!
Так что
Это еще одно подтверждение, что вы потеряли нить обсуждения.
— верно, но только относительно вас. Ну, почти верно — так как вы нить обсуждения, похоже, и не находили. Без обид, по факту.
Именно поэтому я привел примеры, где избавляться от "дублирования" кусков кода не надо.
(…)
Покажите вашу версию этого кода с избавлением от дублирования,
Относительно первого куска — в целом согласен, избавлять от дублирования там не нужно. Просто потому, что там там нет того дублирования, которое вызывает проблемы и к которому следует применять принцип DRY.
То есть, не потому, что вы нашли хороший пример, представляющий код, к которому не нужно применять принцип DRY. А потому что пример неудачный — он иллюстарирует ситуацию, не попадающую под этот принцип. Повторяющаяся последовательность символов в вашем коде — это ещё не дублирование (не то дублирование, про которое идёт речь в DRY.
Точнее, дублирование в вашем примере скорее всего его нет. Просто по приведённому фрагменту об этом невозможно судить. Это ещё раз показывает, что данный пример неудачен.
Чтобы точно судить, есть ли дублирование в той системе, надо смотреть контекст: как используются, как работают и на сколько связаны между собой Категория и Продукт. И, если дублирование всё же обнаружится, то способ избавления от него всё равно должен будет подбираться по тому же контексту…
…Но если я начну углубляться в эту тему, придётся говорить о плохих формулировках принципа DRY (например, о каких "повторениях информации различного рода" идёт речь и до каких приделов предлагается это повторение "снижать" в статье на Wikipeda?), проводить исследования о реальных истоках и основаниях этого принципа, о диффузии и инверсии смысла… — это очень долго и в данном контексте не имеет большого смысла.
Относительно второго примера… Хотя разбирать его подробно тоже не имеет большого смысла, но здесь его даже чуть больше, так что и его прокомментирую.
Тут всё зависит от того, как много у вас классов объектов, которые нужно уметь создавать из соответствующей DTO-шки и сохранять. И на сколько сильно повторение этой "процедуры" влияет на деятельность разработчиков.
Если у вас таких объектов не много (например, как в вашем примере, ровно два), то я бы так делать не стал, а записал бы в "тех.долг".
Если же система, напримре, активно развивается, в неё регулярно добавляются всё новые и новые классы, и подобного рода "процедуры" приходится кодить часто, то я бы подумал над тем, чтобы избавиться от такого дублирования.
Для этого я бы создал объект, который знает, как создать и сохранить правильный объект из DTО. И, кстати, это была бы единственная функциональность этого объекта — гарантия, что он не разрастётся до пресловутого "монстра".
Разумеется, я бы не стал создавать базовый класс для упомянутых в вашем сервисов и выносить эту функциональность туда. Как именно такой объект был бы реализовано зависит от используемого языка и его объектной модели. В Java с её якобы "строгой типизацией" пришлось бы подумать и поизвращаться (и это ещё один аргумент отложить избавление от такого дублирования до того момента, когда связанные с ним неудобства начнут перевешивать расходы на избавление от него …но, обращу внимение, отложить, а не вообще забить на это дублирование, или, тем более, утверждать, что это нормально и даже хорошо). А, например, в Smalltalk-е и Ruby (по второму не уверен, это, скорее, гипотеза) всё было просто и органично. Как это сделать в PHP (вы же на нём свои примеры привели?) — без понятия, никогда не имел с ним дела.
Кстати, по поводу решения о том, нужно ли избавляться от дублирования немедленно или лучше отложить, есть известная (сейчас не помню, где оно изложено — при необходимости найду) эвристика: если ты первый раз заметил дублирование (то есть, обнаружил два сходных по смыслу "куска кода"), то запомни этот факт. если обнаружил тот же дублирование ещё раз (есть три похожих по смыслу куска) — уже есть смысл повнимательнее исследовать и решить, есть ли там дублирование. Для себя я к нему добавил такой пункт: если я в какой-то момент осознаю, что уже не могу легко и быстро вспомнить/найти все места, где просходило такое дублирвоание, то выношу задачу по избавлению от него наверх своего бэклога. На практике неплохо работает.
Я не знаю, зачем вы начали спорить.
Затем, чтобы показать: неверное понимание и использование DRY (как и любой другой не слишком хорошо формализованной, но разумной и полезной практики) может привести к плачевным результатам (и вы это прекрасно продемонстрировали своими примерами) но не имеет никакого отношения к самому принципу.
DRY предлагает некоторый критерий для обнаружение "плохого" кода. Но вообще, формулировки этого принципе мне не нравятся — они переусложнены, запутывают и скрывают настоящий смысл. Но, как я уже сказал, это отдельная большая тема. Избавлять от разного рода "плохого" дублирования (в идеале — от любого) необходимо. Объяснить, как именно, находить дублирование и оценивать его — сложно. Но это не значит, что не нужно вообще. Просто понимание придёт с практикой.
(Раз уж упомянул и его тоже затронули.) YAGNI представляет собой гипотезу, что не надо пытаться предугадывать (фантазировать про) возможные будущие проблемы, а делать только то, что нужно здесь и сейчас.
И первый и второй принцип подтверждаются практикой. И то, что кто-то их используется неправильно — не опровергает их полезность, лишь говорит о том, что их нужно правильно понять и освоить, как и любой другой полезный инструмент.
Но понять и освоить нужно правильно. И исходное высказывание про DRY, и приведённые вами "примеры" является как раз иллюстрацией неправильного понимания идеи и, соответственно, неадекватной её критики.
Например, ваши примеры и высказывания говорят о том, что вы не очень хорошо понимаете, о каком дублировании идёт речь. Я вбросил словосочетание "кусок кода". Вы незамедлительно за него ухватились, ведь ваши примеры — это тоже куски кода. Но тогда тогда и любая буква где-то в коде — это тоже "кусок кода", не так ли? И, следуя DRY, нужно избавляться от всех повторов этой буквы? Судя по вашим примерам и высказываниям , вы должны ответить положительно. А по-моему — нет.
Основываясь на такой доведенной до абсурда трактовке DRY, можно сделать вывод, что это принцип вообще плохой. Где-то в комментариях уже предлагали заменить его на PRY. Но это лишь логическая ошибка. Либо намеренно используемый полимеческий манипулятивный приём.
Контекст того, что "завтра" что-то понадобится, задан в комментарии, на который вы отвечали, в виде утверждения "потом разрастались до монстров".
То, что человек утром проснулся и почистил зубы, а потом в тот же день его на улице сбил автомобиль, не значит, что не нужно чистить зубы.
DRY предлагает некую эвристику, помогающую определить, что, возможно, следует почистить зубы. А YAGNI говорит, что не стоит переживать, что из-за чистки зубов вы попадёте под автомобиль.
Если у вас есть дублирование (сработал DRY), которое ухудшает дизайн вашего кода, и вы смогли от него избавиться, улучшив дизайн кода (здесь DRY уже ничем не поможет), а потом через какое-то время ваш код превратился в монстра, то это не говорит о том, что не надо было улучшать дизайн. А если вы избавились от дублирования так, что дизайн ухудшился, то это не говорит о том, что не надо было избавляться от дублирования.
Первый момент недопонимания заключается в том, что люди, похоже, объединяют всю архитектуру вместе.
Оригинал:
The first misunderstanding is that folks seem to lump all design together.
Design — это не архитектура! Design — это дизайн! Можно перевести как "замысел", "конструкция". Даже "проект" уже не надо — будет путать читателя. Но переводя как "архитектура", вы радикально меняете смысл, так как термин "архитектура" всегда нес иную смысловую нагрузку, а сейчас, когда под "архитектурой" стало модно понимать вообще нечто чуть ли не ортогональное основной функциональности программной системы, и подавно.
Да, под дизайном в России чаще понимают всякие там "украшательства". Но даже "заимствовать" (хотя это никакое не заимствование) слово из совершенно другой области человеческой деятельности будет гораздо лучше, чем нагрузить другим смыслом уже занятый термин из той же области. То, что под словом "дизайн" в этой статье понимается совсем не цвет кнопочек и размер шрифта, будет очевидно из контекста. А вот то, что речь идёт про дизайн (конструкцию) программной системы, а не про её архитектуру — поди ещё догагдайся.
Не знаю, откуда пошла традиция переводить "design" как "архитектура" — от DDD Evans-а в редакции Бродового, или ещё раньше, но с этим надо как-то заканчивать.
Переводчики несут львиную долю ответственности за непонимание и неверную трактовку русскоязычным IT-сообществом многих понятий. Взять то же TDD — это не "Разработка через тестирование"! Тестирование — абсолютно отдельный вид деятельности, принципиально отличающий от разработки. Там просто напросто цели другие. Написание автоматического теста — ещё не тестирование. Зато у нас с момент выхода перевода TDD by Example эта методология трактуется как способ покрыть код тестами. И уже скоро 20 лет как это перебороть никто не может.
Нет, видимо это вы не поняли, о каких примерах шла речь. Или сделали вид — не знаю.
Вы спросили про примеры, когда не надо делать абстракцию, я привел примеры.
Можно было еще привести пример метода тепа Calculator >> twoPlusTwo return 2 + 2. — тоже пример кода, в котором "не надо делать абстракцию" (на самом деле, даже в нём надо).
Я делаю вывод, что в этих примерах абстракцию делать не надо.
Абстракцию делать надо. Просто абстракция — это не вынос родительского класса.
обе функции могут (и скорее всего будут) меняться независимо друг от друга
Любые две функции, пока они две разные "функции", будут меняться независимо. И именно поэтому, надо выявлять куски кода (не обязательно "функции"), которые связаны между собой и искать способ избавляться от этого дублирования.
Сегодня он тривиальный, завтра (…)
YAGNI.
У нас с вами здесь спора не получится. Я подозреваю, что мы придерживаемся принципиально разных взглядов на разработку и даже вкладываем разный смысл в одни и те же термины. Предлагаю просто не тратить ни ваше, ни моё время.
Нужно ли выносить int $id в абстракцию BaseEntity? Нет.
Здесь нет дублирования функциональности. Её (функциональности) здесь в принципе нет.
Нужно ли делать BaseCrudService, который будет вызывать new и save, с абстрактным методом loadDataToEntity($entity, $dto), который переопределяется в наследниках? Нет.
Вы серьёзно?! У вас два раза написан тривиальный код, который практически ничего не делает, и вы всерьёз рассматриваете вариант по созданию базового класса, в котором будет вызываться конструктор? И из-за того, что этот …мммм, как бы помягче… не самый удачный вариант действительно оказывается …не самым удачным, делаете вывод, что DRY это плохо, а дублирование это хорошо? Я вас правильно понял?
нужны детально прописаные требования, причем финализированные - иначе адище вам гарантирован
А если TDD не использовать, то без ясных требований прямая дорога в рай? ;D
Ясные требования нужны в любом случае. И TDD заставит их прояснить. Без TDD — да, можно какое-то время изображать деятельность.
К тому же, TDD даст возможность прояснять требования постепенно, двигаясь маленькими быстрыми шагами — это позволяет часто выдавать новые версии, использовать их на практике и получать быструю обратную связь: правильно поняли очередной "кусок" или нет. На вопрос, как без TDD кто-то умудряется организовать "agile-" разработку, я ни разу не получил вменяемого ответа. Впрочем, я и вменяемого agile-процесса на практкие, к сожалению, до сих пор не видел, одни scrum-ные потёмкинские деревни.
А про бесплатную(!) страховочную сеть в виде тестов, которая позволяет спокойно вносить любые изменения в существующую систему, пишут даже те, кто TDD не понимает.
Да, пожалуйста — придумывайте любые методики, какие захотите. Просто не называйте их так же, как уже существующие. Путаницы и так хватает с огромным избытком.
Очередное выдёргивание, переворачивание, повторение одних тех же уже множество раз опровергнутых тезиов. На этом всё. Удачи вам в вашем нелёгком труде, который вы успешно делаете ещё более тяжёлым.
Пишу. И если бы вы только захотели, вы бы поняли, что “фантазиями” я называю преждевременные и необоснованные предположения о том, как система может развиваться в будущем. А не то, что было удобно увидеть вам.
…И вы в каждом приложении дублируете их реализацию. Понимаю. Это делают (почти) все.
Неверное утверждение, основанное на неверных посылках.
Надеюсь, вы не рассчитывали, что я буду вникать в перипетии вашей задачи? Уверен, что нет. Почти уверен, что это нужно лишь для того, чтобы в очередной раз сказать, что я "ухожу от темы". Что, кстати, тоже является ложным утверждением.
Но если всё же вдруг рассчитывали, то вынужден вас огорчить. Мне, очевидно, некогда разбираться в деталях ваших задач. Вам за них платят деньги, а не мне. А у меня свои задачи есть.
К тому же смысла в таких разбирательствах относительно изначально поднятой темы (sic! не темы решения ваших конкретных примеров-упражений, а темы про DRY) я не вижу.
Во-первых, как вы верно заметили, подобное происходит буквально в каждом проекте. И при этом есть люди, которые утверждают, что дублирование устранять необходимо. Значит, для них это работает.
Во-вторых, на любое предложенное решение конкретной задачи вы будете отвечать накидыванием новых задач по типу "а если пришёл менеджер/бизнес/кто-то и докинул требовний". Это бесконечный процесс, который хорошо позволяет только кидаться разными обвинениям в адрес оппонента, но ничего не даёт с точки зрения обоснования работоспособности подхода.
То, что я успел посмотреть — никаких особых проблем не представляет, всё вполне обыденно и решается в рамках стандартного итерацинного подхода к разработке сложных систем — небольшими шагами, чередующими добавление новой функциональности и рефакторинг. Последний — с тем самым устранением дублирования с целью упрощения системы, что позволяет упростить и добавление новой функциональности. И да, существующий код время от времени переписывается. В этом нет ничего страшного или плохого. Как раз наоборот — позволяет избежать создания необоснованно сложных "универсальных" решений на основе тех самых фантазий разработчиков.
В общем, этот "мой" (если бы это был действительно мой, я бы считал, что жизнь прожита не зря; но я, к сожалению не автор, а всего лишь пользователь) метод как раз обеспечивает и простоту внесения изменений в код (как раз за счёт устранения дублирования), и упрощает понимание (за счёт абстрагирования).
Очередной "уход от темы" завершён, на этом разрешите откланяться.
(Безотносительно данной перепалки и не в упрёк…)
У меня возникло ощущение, что вы в ходе дискуссии упорно демонстрируете когнитивное искажение, называемое Confirmation Bias (не помню, как его назвали на русском), задавшись некоторым предположением, ищете в высказываниях собеседника то, что подтверждает его, и старательно игнорируете то, что может его опровергнуть.
Было несколько примеров. Если вы это делаете осознанно, тогда просто проигнорируйте это замечание — можно не доказывать, что это не так, я не настаиваю на истинности этого наблюдения.
Если же это делается не намеренно, то, проанализируйте — вдруг это подтвердиться, и вы захотите это исправить.
Я уже едва сдерживаюсь, но ладно, пока есть силы, продолжим эту игру :D
Category class >> from: categoryDto^ self new
name: categoryDto name.
parentId: categoryDto parentId.
Product class >> from: productDto^ self new
name: productDto name;
categoryId: productDto categoryId.
Вам именно этого не хватало для полного счастья?
Или нужно добавить, что если, например, делать раз за разом одно и то же (например, клепать админки), и он заметит, что создание админок — это на …(подставьте нужное значение)% и есть дублирование, и решит это дублирование вынести в отдельный фреймворк, то в нём появится примерно такой код:
DtoReader >> create: aModelClass from: aDtoself initialize: aModelClass new from: aDto.^
DtoReader >> initialize: anObject from: aDtovaluesByName := aDto ivarWithValues.
anObject ivarNames do: [:ivarName |
valuesByName
ifKeyPresent: ivarName
doWithValue: [:value |
anObject at: ivarName put: value ].
].
…А Category, Product и все другие классы, в которых будет требоваться функциональность чтения из DTO, будут в этом фрейворке регистрироваться. И этот фрейворк будет в нужных точках с помощью DtoReader-а создавать их экземпляры? (Да, это был вопрос.)
Код этого фреймворка я приводить по понятным (тем, кто захочет понять) и даже очевидным причинам. Тем более, что при написании такого фрейворка в нормальной объектной среде в принципе не возникнет никакой необходимости в DTO.
…:Будет 11-е повторение? Если будет, вы уж уточните тех.задание. А то я спрашиваю-спрашиваю, реализацию какой именно функциональности и в каких именно рамках вы так жаждете увидеть, а вы всё игнорируете и игнорируете. Всё повторяете одно и то же, и повторяете. Я, вроде бы понимаю, а вы говорите, что нет. И опять повторяете то же самое.
Гениально! Так вы собираетесь заставлять меня писать код до каких пор? До кода виртуалной машины? Или инструкций процессора? Может до схемы на платах компьютера и устройства процессра? Ведь на каждом этапе будет отсылка на что-то сложное, очень часто даже гораздо более сложное, чем исходная задача. Вы действительно не понимаете, что такое абстракция? Не понимаете разницу между essential complexity и accidental complexity? Не понимаете, что первую устранить можно, только изменив постановку задачи, и с ней приходится жить? Что эту сложность побороть можно (только?) методом "разделяй и властвуй"? Что суть ОО-дизайна состоит как в распределении сложности между объектами и затем их комбинации?
Ну, хорошо. Давайте ещё на одну ступеньку вниз спустимся. В текущем понимании, думаю, достаточно будет такой реализации:
Mapper >> modelClassByDto: aDto
^ modelClassByDto at: aDto class.
Mapper class >> newWithMapping: classToClassDictionary
^ serlf new
modelClassByDto: classToClassDictionary
Вот инициализация, а то ж вы не поверите:
Applicaiton >> initializeself mapper: Mapper newWithMapping: (
Dictionary newFrom: {
CategoryDto -> Category.
ProductDto -> Dto.
}
).
Как пройтись переменным экземпляра DTO и передать их значение в конструктор модели, расписывать, надеюсь, не нужно?
Возможно, вы захотите придраться к "захардкоженому" в методе словарю. Но поверьте, я без проблем вынесу это дело, обеспечив инъекцию зависимостей. Например, через аннотации.
В очередной раз объяснять вам, что это всё в принципе нереалистично, наверное, бесполезно? Уверен, что да. Но вдруг это еще кто-то будет читать. Оставлю как примечание на такой случай.
Обсуждать пример имеет смысл в некотором контексте. А контекст довольно большой и продолжает расти.
А если без контекста… Ну, вот я ваш код заменю на такой:
Mapper >> createModelFrom: aDtoDto: aDto) from: aDto.^ (self modelClassBy
Вы же опять скажете, что всю сложность "замёл под ковёр"? Хотя, по факту, это и есть абстракция через распределение ответственности между объектами. Там придётся подтягивать ещё и обсуждение "анемичные модели (по факту процедурное программирование) против ООП (это я вам в самом начале писал, вот оно — вылезает потихоньку).
Вся наша перепалка уже давно свелась к вопросам о том, что понимать под "дублированием" и любое ли "дублирование" можно устранить, упростив при этом систему", а так же"что хотел сказать автор?".
Первые два просто не помещаются в формат комментариев.
А по последнему — это про
Если не вдаваться в детали, примерно так и есть.
Автор статьи, даже если хотел сказать что-то другое, явно и однозначно предложил отказаться от DRY. Других вариантов трактовки смысла написанного под заголовком (которого, в принципе уже достаточно) "Да, пожалуйста, повторяйтесь" я при всём желании найти не могу. Хотя честно пытался (ещё до того, как меня таки угораздило втянуться в эту перепалку). Но получилось сгенерировать лишь две версии такого “совмещения”:
В одних случаях не повторяемся, в других повторяемся. В этой идее, кстати (как я раньше уже писал) в нет ничего нового, она изначально заложена в идее “устраняем дублирование”, так как хочешь-не хочешь, но сначала придётся определиться, что понимать под дублирование. Очевидно же, — и про это я тоже уже писал — что, например, устранять дублирование отдельных символов в коде не имеет смысла. Но у автора статьи про это нет ни слова — не то, что про определение понятия “дублирование” или критерий применимости DRY, даже про саму возможность такого выбора. То ест, здесь просто предлагается заменить DRY на PRY. Я где-то здесь ошибаюсь?
Двоемыслие. Этот вариант вряд ли заслуживает подробного рассмотрения — не так ли?
Автор комментария, который послужил непосредственным поводом к этой дискуссии, особых возражений к изложенному в статье или новых трактовок не выдвинул, но косвенно — поделившись своим опытом — вроде как предложил некий критерий в русле п.1. Именно так я понял изначально его мысль и именно поэтому попросил примеры. Какие именно примеры могли бы подтвердить данный подход— см. мои предыдущие сообщения. Это не те примеры, которые вы привели.
Почему же я приравниваю изложенную в том комментарии точку зрения к призыву отказа от DRY? По той же причине — отсутствия чёткого критерия применимости этого принципа. Конкретно, что предлагает автор комментария:
То есть, предлагается устранять дублирование только внутри отдельного “пакета”, который кто-то когда-то по каким-то причинам решил выделить. Это, конечно, не такой категорический отказ, какой предлагается в статье, но тем не менее именно отказ, так как “100500” представляет собой практически синоним слова “бесконечность”, В купе с неясными критериями деления по пакетам такой подход делают критерий применимости DRY абсолютно размытым и, по сути, даёт зеленый свет к тому же самому отказу от DRY по принципу "Не знаешь, как устранить дублирование? Просто забей!"
Кроме того, в этом комментарии содержится серьезный логический изъян (или когнитивное искажение) — на что я тоже ранее уже указывал (как же часто мне приходится повторять то, что я ранее всё это уже излагал!):
Между "устранением дублирования" и "превращением абстракции в монстра" здесь нет причинно-следственной связи. Устранение DRY — это рефакторинг, который должен упрощать систему, так дублирование — это как раз усложнение.
Итог: оба автора предлагают в той или иной степени ограничить использование DRY. Один — радикально, другой — через неясные, размытые критерии.
Возможно, и эти авторы, и вы пытались сказать что-то другое? Возможно. Но в таком случае это просто не удалось сделать. Разумеется, с моей — субъективной и не претендующей на окончательную истинность — точки зрения.
P.S.: Да, опять получилось много букв (и это только мЕньшая часть из уже написанных) и мало кода. Но это не потому, что, (как вам явно хочется думать) я не умею его писать или редко это делаю или пишу "игрушечный" код. Это не так. Просто вы сами задали такие условия "игры" …что — уже надоело, но я ещё раз это отмечу — я уже не раз здесь заявлял.
Да, я решил, что вам это интересно, так как вы систематически игнорировали все мои попытки прекратить эту (как мне на тот момент казалось) бессмысленную дискуссию, и, напротив, всячески её поддерживали. А когда я всё-таки увидел хоть какой-то смысл, вы тут же заявили, что вам не интересно. Ну, хорошо. Дело хозяйское :)
Извините, конечно :) но я буду делать то, что интересно и нужно мне. То, что вас интересует, "меня интересует меньше. Интересует. Но меньше." (с)
У меня нет цели убедить лично вас в чём-то или победить в это "споре". За 25 лет в программировании я принял участие в разработке довольно большого количества проектов. По крайней мере, достаточное для того, чтобы сформировать своё понимание, много раз уточнить/скорректировать и проверить его. Данная дискуссия навела меня на некоторые мысли и даже, в конечном счёте, на очередные корректировки. Ими я и собираюсь поделиться. Но удовлетворение ваших запросов — это ваше собственное дело.
Dynabook
Я не слился ;) Отвечу позже (когда будет время) и, скорее всего, не здесь — в рамках комментариев уже стало совсем тесно. Ссылку, разумеется, сюда скину.
Теперь откройте мой комментарий и прочитайте, что там написано. Соотнесите. Подумайте. Попробуйте понять. Я ещё долго могу продолжать, но, может, всё-таки откажемся от императивного стиля? ;)
Неправильно. Теперь откройте текст статьи и комментариев и прочитайте, что там написано.
У вас наблюдается удивительная "сверх"-способность видеть и понимать то, что не было написано, и не понимать то, что написано :)
Без особой надежды на понимание постараюсь еще раз — максимально просто и кратко…
========================= Начало пояснения
В статье предлагается следующая логика (это не цитата, просто других способов выделить текст не нахожу):
Это на столько дико, что спорить с этим я вообще не вижу смысла. От короткого комментария по этому поводу не удержался, но на этом всё.
А вот с комментарием, на который я ответил, я вообще не спорил. Где вы это вообще обнаружили? …А, ну да — сверх-способности же ;) Простите.
Я всего лишь попросил пример, когда появившиеся в результате адекватного применения DRY …
В ответ на это вы привели абсолютно неадекватные примеры, на что я вам и указал. И тут понеслось… :D
Адекватным примером был бы:
Кусок функциональности, к которому имеет смысл применить DRY
Результат этого рефакторинга — "невинная абстракция"
Какой из этого в итоге получился монстр, и его связь с предыдущим рефакторингом
========================= Конец пояснения
А с чем я действительно готов спорить по поводу DRY, я подробно объяснил ранее. Но вы это проигнорировали, как это модно было говорить, "чуть более, чем полностью".
Если действительно так, то это печально. Остаётся только пожалеть вас и всех, кто связан с подобными проектами. Но я всё же подозреваю, что вы утрируете. …Но этим, в общем-то, и ограничивается связь приведённого вами ужасающего факта с дискуссией по поводу DRY.
Да, согласен. Занесло :) Но если вы так и не поняли, то этот момент у меня возражений как раз не вызывал.
У вас какие-то проблемы с логикой? То, что я повторил и более подробно раскрыл мысль, вскользь упомянутую выше и не имеющую прямого отношения к обсуждаемой проблеме, говорит именно об этом? Другие варианты исключены?
Если вы не отвечаете нет, то это говорит о том, что ваши "примеры" неадекватны. Что я с самого начала до вас и пытался донести — об этом выше.
Остаётся только понять, вы эти привели по недоразумению или намеренно, для троллинга? Ну, чтобы завязать спор на пустом месте и всеми неправдами пытаться в нём победить. Ок, вы победили. На этом завершим? Я ниже только ещё отвечу на некоторые интересные моменты. Но можем считать, что на результат это не влияет — вы блистательно победили!
Это тоже говорит о том, что вы так и не поняли или не захотели понять смысл моего комментария.
В моей системе на Smalltalk-е DTO скорее всего не было бы в принципе. Но если вам так хочется кода, пожалуйста:
EntityService >> createFrom: aDtomodel = mapper createModelFrom: aDto.
entityManager save: model.
^ model
Вы предлагаете не добавлять новую функциональность, а не устранять дублирование — это рефакторинг, так как на существующую функциональность это действие как раз влиять не должно.
А делать это, точнее не делать, вы предлагаете из каких-то смутных фантазий о том, что когда-то в будущем это может привести к проблемам. Вот здесь и возникает You Are Not Gonna Need It — решать какие-то смутные будущие проблемы.
И ещё раз (вдруг всё-таки поймёте) обращу ваше внимание, что мой исходный вопрос как раз был про эти будущие проблемы.
Не, зачем 20? 4-х достаточно. Но Вам это сильно помогло? Возможно, для вас это станет сюрпризом, но смысл кода не всегда ясен из самого кода. Иногда нужен контекст. А это будет значительно больше 20 строк.
И у вас опять наблюдаются проблемы с логикой Ну, с трактовкой-анализом имеющихся фактов и выводами из них.
Только прошу понять правильно и не расценивать как переход на личности. Это просто к сомнениям о целесообразности продолжения этой перепалки. Получить нужные примеры надежду я уже давно потерял. Полезного спора как с самого начала не получалось, так до сих пор, к сожалению не намечается.
Трудности перевода, понимаю. Но "архитектура" — один из худших вариантов, правда.
Хорошо, уговорили, потрачу ещё какую-то часть своего бесценного времени в надежде, что это кому-нибудь чем-нибудь поможет.
Читаем внимательно и не выдёргиваем из контекста. Комментарий начинается словами:
Про что разговор? Про DRY!
Так что
— верно, но только относительно вас. Ну, почти верно — так как вы нить обсуждения, похоже, и не находили. Без обид, по факту.
Относительно первого куска — в целом согласен, избавлять от дублирования там не нужно. Просто потому, что там там нет того дублирования, которое вызывает проблемы и к которому следует применять принцип DRY.
То есть, не потому, что вы нашли хороший пример, представляющий код, к которому не нужно применять принцип DRY. А потому что пример неудачный — он иллюстарирует ситуацию, не попадающую под этот принцип. Повторяющаяся последовательность символов в вашем коде — это ещё не дублирование (не то дублирование, про которое идёт речь в DRY.
Точнее, дублирование в вашем примере скорее всего его нет. Просто по приведённому фрагменту об этом невозможно судить. Это ещё раз показывает, что данный пример неудачен.
Чтобы точно судить, есть ли дублирование в той системе, надо смотреть контекст: как используются, как работают и на сколько связаны между собой Категория и Продукт. И, если дублирование всё же обнаружится, то способ избавления от него всё равно должен будет подбираться по тому же контексту…
…Но если я начну углубляться в эту тему, придётся говорить о плохих формулировках принципа DRY (например, о каких "повторениях информации различного рода" идёт речь и до каких приделов предлагается это повторение "снижать" в статье на Wikipeda?), проводить исследования о реальных истоках и основаниях этого принципа, о диффузии и инверсии смысла… — это очень долго и в данном контексте не имеет большого смысла.
Относительно второго примера… Хотя разбирать его подробно тоже не имеет большого смысла, но здесь его даже чуть больше, так что и его прокомментирую.
Тут всё зависит от того, как много у вас классов объектов, которые нужно уметь создавать из соответствующей DTO-шки и сохранять. И на сколько сильно повторение этой "процедуры" влияет на деятельность разработчиков.
Если у вас таких объектов не много (например, как в вашем примере, ровно два), то я бы так делать не стал, а записал бы в "тех.долг".
Если же система, напримре, активно развивается, в неё регулярно добавляются всё новые и новые классы, и подобного рода "процедуры" приходится кодить часто, то я бы подумал над тем, чтобы избавиться от такого дублирования.
Для этого я бы создал объект, который знает, как создать и сохранить правильный объект из DTО. И, кстати, это была бы единственная функциональность этого объекта — гарантия, что он не разрастётся до пресловутого "монстра".
Разумеется, я бы не стал создавать базовый класс для упомянутых в вашем сервисов и выносить эту функциональность туда. Как именно такой объект был бы реализовано зависит от используемого языка и его объектной модели. В Java с её якобы "строгой типизацией" пришлось бы подумать и поизвращаться (и это ещё один аргумент отложить избавление от такого дублирования до того момента, когда связанные с ним неудобства начнут перевешивать расходы на избавление от него …но, обращу внимение, отложить, а не вообще забить на это дублирование, или, тем более, утверждать, что это нормально и даже хорошо). А, например, в Smalltalk-е и Ruby (по второму не уверен, это, скорее, гипотеза) всё было просто и органично. Как это сделать в PHP (вы же на нём свои примеры привели?) — без понятия, никогда не имел с ним дела.
Кстати, по поводу решения о том, нужно ли избавляться от дублирования немедленно или лучше отложить, есть известная (сейчас не помню, где оно изложено — при необходимости найду) эвристика: если ты первый раз заметил дублирование (то есть, обнаружил два сходных по смыслу "куска кода"), то запомни этот факт. если обнаружил тот же дублирование ещё раз (есть три похожих по смыслу куска) — уже есть смысл повнимательнее исследовать и решить, есть ли там дублирование. Для себя я к нему добавил такой пункт: если я в какой-то момент осознаю, что уже не могу легко и быстро вспомнить/найти все места, где просходило такое дублирвоание, то выношу задачу по избавлению от него наверх своего бэклога. На практике неплохо работает.
Затем, чтобы показать: неверное понимание и использование DRY (как и любой другой не слишком хорошо формализованной, но разумной и полезной практики) может привести к плачевным результатам (и вы это прекрасно продемонстрировали своими примерами) но не имеет никакого отношения к самому принципу.
DRY предлагает некоторый критерий для обнаружение "плохого" кода. Но вообще, формулировки этого принципе мне не нравятся — они переусложнены, запутывают и скрывают настоящий смысл. Но, как я уже сказал, это отдельная большая тема. Избавлять от разного рода "плохого" дублирования (в идеале — от любого) необходимо. Объяснить, как именно, находить дублирование и оценивать его — сложно. Но это не значит, что не нужно вообще. Просто понимание придёт с практикой.
(Раз уж упомянул и его тоже затронули.) YAGNI представляет собой гипотезу, что не надо пытаться предугадывать (фантазировать про) возможные будущие проблемы, а делать только то, что нужно здесь и сейчас.
И первый и второй принцип подтверждаются практикой. И то, что кто-то их используется неправильно — не опровергает их полезность, лишь говорит о том, что их нужно правильно понять и освоить, как и любой другой полезный инструмент.
Но понять и освоить нужно правильно. И исходное высказывание про DRY, и приведённые вами "примеры" является как раз иллюстрацией неправильного понимания идеи и, соответственно, неадекватной её критики.
Например, ваши примеры и высказывания говорят о том, что вы не очень хорошо понимаете, о каком дублировании идёт речь. Я вбросил словосочетание "кусок кода". Вы незамедлительно за него ухватились, ведь ваши примеры — это тоже куски кода. Но тогда тогда и любая буква где-то в коде — это тоже "кусок кода", не так ли? И, следуя DRY, нужно избавляться от всех повторов этой буквы? Судя по вашим примерам и высказываниям , вы должны ответить положительно. А по-моему — нет.
Основываясь на такой доведенной до абсурда трактовке DRY, можно сделать вывод, что это принцип вообще плохой. Где-то в комментариях уже предлагали заменить его на PRY. Но это лишь логическая ошибка. Либо намеренно используемый полимеческий манипулятивный приём.
То, что человек утром проснулся и почистил зубы, а потом в тот же день его на улице сбил автомобиль, не значит, что не нужно чистить зубы.
DRY предлагает некую эвристику, помогающую определить, что, возможно, следует почистить зубы. А YAGNI говорит, что не стоит переживать, что из-за чистки зубов вы попадёте под автомобиль.
Если у вас есть дублирование (сработал DRY), которое ухудшает дизайн вашего кода, и вы смогли от него избавиться, улучшив дизайн кода (здесь DRY уже ничем не поможет), а потом через какое-то время ваш код превратился в монстра, то это не говорит о том, что не надо было улучшать дизайн. А если вы избавились от дублирования так, что дизайн ухудшился, то это не говорит о том, что не надо было избавляться от дублирования.
Разве это не очевидно? ;)
Перевод:
Оригинал:
Design — это не архитектура! Design — это дизайн! Можно перевести как "замысел", "конструкция". Даже "проект" уже не надо — будет путать читателя. Но переводя как "архитектура", вы радикально меняете смысл, так как термин "архитектура" всегда нес иную смысловую нагрузку, а сейчас, когда под "архитектурой" стало модно понимать вообще нечто чуть ли не ортогональное основной функциональности программной системы, и подавно.
Да, под дизайном в России чаще понимают всякие там "украшательства". Но даже "заимствовать" (хотя это никакое не заимствование) слово из совершенно другой области человеческой деятельности будет гораздо лучше, чем нагрузить другим смыслом уже занятый термин из той же области. То, что под словом "дизайн" в этой статье понимается совсем не цвет кнопочек и размер шрифта, будет очевидно из контекста. А вот то, что речь идёт про дизайн (конструкцию) программной системы, а не про её архитектуру — поди ещё догагдайся.
Не знаю, откуда пошла традиция переводить "design" как "архитектура" — от DDD Evans-а в редакции Бродового, или ещё раньше, но с этим надо как-то заканчивать.
Переводчики несут львиную долю ответственности за непонимание и неверную трактовку русскоязычным IT-сообществом многих понятий. Взять то же TDD — это не "Разработка через тестирование"! Тестирование — абсолютно отдельный вид деятельности, принципиально отличающий от разработки. Там просто напросто цели другие. Написание автоматического теста — ещё не тестирование. Зато у нас с момент выхода перевода TDD by Example эта методология трактуется как способ покрыть код тестами. И уже скоро 20 лет как это перебороть никто не может.
Нет, видимо это вы не поняли, о каких примерах шла речь. Или сделали вид — не знаю.
Можно было еще привести пример метода тепа Calculator >> twoPlusTwo return 2 + 2. — тоже пример кода, в котором "не надо делать абстракцию" (на самом деле, даже в нём надо).
Абстракцию делать надо. Просто абстракция — это не вынос родительского класса.
Любые две функции, пока они две разные "функции", будут меняться независимо. И именно поэтому, надо выявлять куски кода (не обязательно "функции"), которые связаны между собой и искать способ избавляться от этого дублирования.
YAGNI.
У нас с вами здесь спора не получится. Я подозреваю, что мы придерживаемся принципиально разных взглядов на разработку и даже вкладываем разный смысл в одни и те же термины. Предлагаю просто не тратить ни ваше, ни моё время.
А, ну я увидел статью про анемичную модель. Дальнейшее обсуждение сведётся к холивару про смысл ООП. Можно не продолжать.
Здесь нет дублирования функциональности. Её (функциональности) здесь в принципе нет.
Вы серьёзно?! У вас два раза написан тривиальный код, который практически ничего не делает, и вы всерьёз рассматриваете вариант по созданию базового класса, в котором будет вызываться конструктор? И из-за того, что этот …мммм, как бы помягче… не самый удачный вариант действительно оказывается …не самым удачным, делаете вывод, что DRY это плохо, а дублирование это хорошо? Я вас правильно понял?
А если TDD не использовать, то без ясных требований прямая дорога в рай? ;D
Ясные требования нужны в любом случае. И TDD заставит их прояснить. Без TDD — да, можно какое-то время изображать деятельность.
К тому же, TDD даст возможность прояснять требования постепенно, двигаясь маленькими быстрыми шагами — это позволяет часто выдавать новые версии, использовать их на практике и получать быструю обратную связь: правильно поняли очередной "кусок" или нет. На вопрос, как без TDD кто-то умудряется организовать "agile-" разработку, я ни разу не получил вменяемого ответа. Впрочем, я и вменяемого agile-процесса на практкие, к сожалению, до сих пор не видел, одни scrum-ные потёмкинские деревни.
А про бесплатную(!) страховочную сеть в виде тестов, которая позволяет спокойно вносить любые изменения в существующую систему, пишут даже те, кто TDD не понимает.
+100500
@kmoseenk , в чём была сложность с переводом слова "каноничный"? ;)
Да, пожалуйста — придумывайте любые методики, какие захотите. Просто не называйте их так же, как уже существующие. Путаницы и так хватает с огромным избытком.