Зачем нам нужно так много классов в шаблонах проектирования?

209

Я младший разработчик среди пожилых людей и много борюсь с пониманием их мышления, рассуждений.

Я читаю доменно-управляемый дизайн (DDD) и не могу понять, почему нам нужно создавать так много классов. Если мы будем следовать этому методу проектирования программного обеспечения, мы получим 20-30 классов, которые можно заменить максимум двумя файлами и 3-4 функциями. Да, это может быть грязно, но гораздо удобнее и понятнее.

В любое время, когда я хочу увидеть, что EntityTransformationServiceImplделает какой-то вид , мне нужно следить за множеством классов, интерфейсов, их вызовов функций, конструкторов, их созданием и так далее.

Простая математика:

  • 60 строк фиктивного кода против 10 классов X 10 (скажем, у нас такие разные логики) = 600 строк беспорядочного кода против 100 классов + еще несколько для их обертывания и управления ими; не забудьте добавить инъекцию зависимостей.
  • Чтение 600 строк беспорядочного кода = один день
  • 100 уроков = одна неделя, все равно забудь, кто что делает, когда

Все говорят, что это легко поддерживать, но для чего? Каждый раз, когда вы добавляете новые функции, вы добавляете еще пять классов с фабриками, объектами, службами и значениями. Я чувствую, что этот код движется намного медленнее, чем грязный код.

Скажем, если вы пишете грязный код 50K LOC за один месяц, DDD требует много проверок и изменений (я не против тестов в обоих случаях). Одно простое дополнение может занять неделю, если не больше.

За один год вы пишете много грязного кода и даже можете переписывать его несколько раз, но в стиле DDD у вас все еще не хватает функций, чтобы конкурировать с грязным кодом.

Пожалуйста, объясни. Зачем нам нужен этот стиль DDD и множество шаблонов?

UPD 1 : Я получил так много отличных ответов. Не могли бы вы, ребята, добавить комментарий где-нибудь или отредактировать свой ответ со ссылкой для списка чтения (не уверен, с чего начать, DDD, Шаблоны проектирования, UML, Выполнение кода, Рефакторинг, Прагматика, .. так много хороших книг), конечно, с последовательностью, так что я также могу начать понимать и становиться старше, как некоторые из вас.

user1318496
источник
81
Я думаю, что здесь есть хороший вопрос, но он скрывается за гиперболой и разочарованием. @ user1318496, вам может быть полезно перефразировать ваш вопрос.
MetaFight
48
С риском наступить на пальцы, потому что ваш язык отстой. Не принимайте это больше, чем это: плохой язык часто является правильным техническим выбором по разным причинам, но это не делает его неудачным. Что касается вашего фактического вопроса, правильность важнее, чем читаемость. Или, говоря немного иначе: удобочитаемость имеет значение, поскольку позволяет рассуждать о правильности. Итак, что легче проверить, ваши 100 классов или ваш класс монолитного бога? Я ставлю на 100 простых классов.
Джаред Смит
87
«Да, это может быть грязно, но гораздо более легко обслуживаемо и читабельно». Если это грязно, как это может быть читаемым и обслуживаемым?
Полигном
37
@Polygnome: я собирался напечатать точно такой же комментарий. Другой характерный комментарий для начинающих разработчиков: «Я чувствую, что этот вид кода движется намного медленнее, чем грязный код». Бегать так быстро, как только можешь, бесполезно, если ты тратишь половину своего времени на бег! Медленно, гладко, гладко быстро.
Эрик Липперт
40
Вы не делаете, если вы не делаете Java. Когда у вас есть только Java, все выглядит как класс.
Хоббс

Ответы:

336

Это проблема оптимизации

Хороший инженер понимает, что проблема оптимизации без цели бессмысленна. Вы не можете просто оптимизировать, вы должны оптимизировать для чего - то. Например, параметры вашего компилятора включают оптимизацию по скорости и оптимизацию по размеру кода; это иногда противоположные цели.

Я хотел бы сказать моей жене, что мой стол оптимизирован для добавления. Это просто куча, и это очень легко добавлять вещи. Моя жена предпочла бы это, если бы я оптимизировал поиск, то есть немного организовал свои вещи, чтобы я мог найти вещи. Это, конечно, усложняет добавление.

Программное обеспечение так же. Вы, безусловно, можете оптимизировать создание продукта - сгенерируйте тонну монолитного кода как можно быстрее, не беспокоясь об его организации. Как вы уже заметили, это может быть очень, очень быстро. Альтернативой является оптимизация технического обслуживания - сделать создание прикосновения более сложным, но сделать модификации более легкими или менее рискованными. Это цель структурированного кода.

Я бы предположил, что успешный программный продукт будет создаваться только один раз, но изменяться много, много раз. Опытные инженеры видели, как неструктурированные кодовые базы начинают жить самостоятельно и становятся продуктами, растущими в размерах и сложности, пока даже небольшие изменения не станут очень трудными для выполнения без значительного риска. Если код был структурирован, риск может быть ограничен. Вот почему мы идем ко всем этим неприятностям.

Сложность проистекает из отношений, а не элементов

Я заметил, что в вашем анализе вы смотрите на количество - количество кода, количество классов и т. Д. Хотя это и интересно, реальное влияние оказывают отношения между элементами, которые взрываются комбинаторно. Например, если у вас есть 10 функций, и вы не знаете, от чего зависит, у вас есть 90 возможных отношений (зависимостей), о которых вам нужно беспокоиться - каждая из десяти функций может зависеть от любой из девяти других функций, и 9 x 10 = 90. Вы можете не знать, какие функции изменяют какие переменные или как данные передаются, поэтому у кодеров есть масса вещей, о которых нужно беспокоиться при решении какой-либо конкретной проблемы. Напротив, если у вас есть 30 классов, но они организованы умно, они могут иметь всего 29 отношений, например, если они наслоены или расположены в стеке.

Как это влияет на пропускную способность вашей команды? Ну, есть меньше зависимостей, проблема гораздо более разрешима; кодеры не должны жонглировать миллионами вещей в своей голове, когда они вносят изменения. Таким образом, минимизация зависимостей может значительно повысить вашу способность грамотно рассуждать о проблеме. Вот почему мы делим вещи на классы или модули, и ограничиваем переменные области видимости, насколько это возможно, и используем принципы SOLID .

Джон Ву
источник
103
Я хотел бы отметить, однако, что переизбыток классов и косвенность не помогают ни пониманию обслуживания NOR. И при этом не запутанные потоки управления (иначе, обратный вызов ада).
Матье М.
9
@JohnWu это объяснение - путь лучший и легче понять то, что я когда-либо читал.
Адриано Репетти
13
Хорошо написано, но, может быть, этого не хватает, почему важно «созданный один раз, но измененный много, много раз»? (Если весь код в EntityTransformationServiceImpl, вы вынуждены учиться , как все это работает , прежде чем вы можете это исправить - но если , например , что - то не так с форматом и Formatterкласс обрабатывает , что вам нужно только , чтобы узнать , как та часть работы Plus. чтение собственного кода через ~ 3 месяца похоже на чтение кода незнакомца.) Мне кажется, что большинство из нас подсознательно думают об этом, но это может быть из-за опыта. Не уверен на 100% в этом.
Р. Шмитц
17
Я бы пошел на полные 10 × 10 = 100 для комбинаторных: эти функции вполне могут быть рекурсивными, и в особенно плохом коде, не обязательно, очевидно, так.
KRyan
32
«Альтернатива состоит в том, чтобы оптимизировать техническое обслуживание - сделать создание прикосновений более сложным, но сделать модификации более легкими или менее рискованными. Это цель структурированного кода». Я не согласен с неявным представлением, что больше классов = больше ремонтопригодности. В частности, логика рассеяния по многим классам часто затрудняет поиск всеобъемлющих логических концепций в коде (особенно без преднамеренного взгляда на то, чтобы эти концепции были очень заметны), что значительно ухудшает удобство сопровождения.
jpmc26
67

Ну, во-первых, читаемость и удобство обслуживания часто находятся в поле зрения зрителя.

То, что читается для вас, может не быть вашим соседом.

Сопровождаемость часто сводится к обнаруживаемости (насколько легко поведение или концепция обнаруживается в кодовой базе), а обнаруживаемость - еще одна субъективная вещь.

DDD

Один из способов, которым DDD помогает командам разработчиков, - это предложить конкретный (но все же субъективный) способ организации концепций и поведения вашего кода. Это соглашение облегчает обнаружение вещей и, следовательно, облегчает поддержку приложения.

  • Концепции домена кодируются как сущности и агрегаты
  • Поведение домена находится в сущностях или доменных службах
  • Последовательность обеспечивается совокупными корнями
  • Постоянные проблемы обрабатываются хранилищами

Такое расположение объективно проще поддерживать. Тем не менее, его значительно легче поддерживать, когда все понимают, что работают в контексте DDD.

Классы

Классы помощь ремонтопригодности, читаемость, понятность и т.д ... потому , что они хорошо известны конвенции .

В объектно-ориентированных настройках классы обычно используются для группировки тесно связанного поведения и для инкапсуляции состояния, которое необходимо тщательно контролировать.

Я знаю, это звучит очень абстрактно, но вы можете думать об этом так:

С классами вам не обязательно знать, как работает код в них. Вам просто нужно знать, за что отвечает класс.

Классы позволяют вам рассуждать о вашем приложении с точки зрения взаимодействия между четко определенными компонентами .

Это уменьшает когнитивную нагрузку при рассуждении о том, как работает ваше приложение. Вместо того, чтобы помнить, что выполняет 600 строк кода , вы можете подумать о том, как взаимодействуют 30 компонентов .

И, учитывая, что эти 30 компонентов, вероятно, охватывают 3 уровня вашего приложения, вы, вероятно, только каждый должен рассуждать о примерно 10 компонентах одновременно.

Это кажется довольно управляемым.

Резюме

По сути, то, что вы видите, делают старшие разработчики:

Они разбивают приложение на легкие рассуждения о классах.

Затем они организуют их в простые рассуждения о слоях.

Они делают это, потому что знают, что с ростом приложения становится все труднее рассуждать об этом в целом. Разбиение его на слои и классы означает, что им никогда не придется рассуждать обо всем приложении. Они только должны рассуждать о небольшом подмножестве этого.

MetaFight
источник
5
Кроме того, меньшие классы легче заменить / рефакторинг.
Заломон
12
Overengineering не дает более понятный или понятный код - как раз наоборот, несмотря на то, что вы утверждаете. Кому нужно, AddressServiceRepositoryProxyInjectorResolverкогда можно решить проблему более элегантно? Шаблоны дизайна ради шаблонов дизайна просто приводят к ненужной сложности и многословности.
Викингстеве
27
Да, переподготовка это плохо. Так убивает щенков. Никто здесь не выступает за то или другое. logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/169/...
MetaFight
5
Кроме того, «элегантность» в контексте разработки программного обеспечения часто является словом «ласка». en.wikipedia.org/wiki/Weasel_word
MetaFight
11
То же самое можно сказать о любом подходе к организации кода. Все зависит от команды поддержки, понимающей, почему код организован так, как он есть. В этом весь смысл использования хорошо установленных и понятных соглашений.
MetaFight
29

Пожалуйста, объясните мне, зачем нам этот стиль DDD, много паттернов?

Во-первых, обратите внимание: важной частью DDD являются не шаблоны , а согласованность усилий разработчиков с бизнесом. Грег Янг отметил, что главы в синей книге расположены в неправильном порядке .

Но на ваш конкретный вопрос: классов, как правило, гораздо больше, чем вы ожидаете, (а) потому, что предпринимаются усилия, чтобы отличить поведение домена от сантехники, и (б) потому, что прилагаются дополнительные усилия для обеспечения того, чтобы концепции в доменной модели выражены явно.

Если говорить прямо, если у вас есть две разные концепции в домене, то они должны быть различны в модели, даже если они совпадают в представлении памяти .

По сути, вы создаете язык, специфичный для предметной области, который описывает вашу модель на языке бизнеса, так что специалист по предметной области должен уметь анализировать его и выявлять ошибки.

Кроме того, вы видите немного больше внимания, уделяемого разделению интересов; и понятие изоляции потребителей некоторых возможностей от деталей реализации. Смотри DL Parnas . Четкие границы позволяют вам изменять или расширять реализацию, не затрагивая эффекты во всем решении.

Мотивация здесь: для приложения, которое является частью основной компетенции бизнеса (имеется в виду место, где оно получает конкурентное преимущество), вы захотите иметь возможность легко и дешево заменить поведение домена лучшим вариантом. По сути, у вас есть части программы, которые вы хотите быстро развить (как состояние изменяется со временем), и другие части, которые вы хотите изменить медленно (как состояние сохраняется); дополнительные уровни абстракции помогают избежать случайного соединения одного с другим.

Справедливости ради: некоторые из них также являются объектно-ориентированным повреждением мозга. Шаблоны, первоначально описанные Эвансом, основаны на проектах Java, в которых он участвовал более 15 лет назад; состояние и поведение тесно связаны в этом стиле, что приводит к сложностям, которые вы, возможно, предпочтете избегать; см. « Восприятие и действие » Стюарта Хэллоуэя или « Встроенный код » Джона Кармака.

Независимо от того, на каком языке вы работаете, программирование в функциональном стиле дает преимущества. Вы должны делать это всякий раз, когда это удобно, и вы должны тщательно продумывать решение, когда это не удобно. Кармак, 2012

VoiceOfUnreason
источник
2
Я собирался добавить свой собственный ответ, пока я не прочитал это. Я хотел бы подчеркнуть первый абзац, что цель состоит в том, чтобы моделировать бизнес-концепции в программном обеспечении, чтобы привести программное обеспечение в соответствие с бизнес-требованиями. Справедливости ради, аналитик, управляющий проектом, должен также выразить, сколько времени у водителя на доставку, и качество или полнота кода / теста должны быть соответствующим образом скорректированы.
Сентинел
1
Джон Кармак - отличный пример IMO, так как он хорошо известен тем, что пишет код, который является чистым и легким для понимания, а также хорошо работает. Это особенно заметно, когда вы отслеживаете его код с помощью передовых технологий - с улучшенными процессорами и памятью, вы можете увидеть множество вещей, от «это должно быть очень кратко» до «это должно быть действительно ясно / изолировано / ...» ». Один из самых прагматичных программистов, которых я знаю :)
Luaan
Я думаю, что это лучший ответ здесь. Хотя я ни в коем случае не продан на DDD, этот ответ определенно, по крайней мере, объясняет, что это такое на самом деле, и фактическую мотивацию для него, а не обращается к общим банальностям, которые ничего не значат.
jpmc26
29

В других ответах есть много хороших моментов, но я думаю, что они упускают или не подчеркивают важную концептуальную ошибку, которую вы совершаете:

Вы сравниваете усилия, чтобы понять всю программу.

Это нереальная задача с большинством программ. Даже простые программы состоят из такого большого количества кода, что просто невозможно управлять всем этим в голове в любой момент времени. Ваш единственный шанс - найти ту часть программы, которая соответствует поставленной задаче (исправление ошибки, реализация новой функции) и работа с ней.

Если ваша программа состоит из огромных функций / методов / классов, это практически невозможно. Вам нужно разобраться с сотнями строк кода, чтобы решить, соответствует ли этот кусок кода вашей проблеме. С оценками, которые вы дали, становится легко потратить неделю, просто чтобы найти кусок кода, над которым нужно поработать.

Сравните это с базой кода с небольшими функциями / методами / классами, названными и организованными в пакеты / пространства имен, которые делают очевидным, где найти / поместить данный фрагмент логики. Во многих случаях, когда все сделано правильно, вы можете прыгнуть прямо в правильное место, чтобы решить вашу проблему, или, по крайней мере, туда, где запуск вашего отладчика приведет вас в нужное место за пару прыжков.

Я работал в обоих видах систем. Разница может легко составить два порядка в производительности для сопоставимых задач и сопоставимого размера системы.

Влияние это оказывает на другие виды деятельности:

  • тестирование становится намного проще с меньшими единицами
  • меньше конфликтов слияния, потому что шансы двух разработчиков работать над одним и тем же фрагментом кода меньше.
  • меньше дублирования, потому что легче повторно использовать кусочки (и найти кусочки в первую очередь).
Йенс Шаудер
источник
19

Потому что тестировать код сложнее, чем писать код

Многие ответы дали веские аргументы с точки зрения разработчика - такое обслуживание может быть сокращено за счет того, что код, в первую очередь, будет более трудоемким для написания.

Однако есть еще один аспект - тестирование может быть только детализированным, как ваш исходный код.

Если вы пишете все в монолите, единственный эффективный тест, который вы можете написать, - «учитывая эти входные данные, правильный ли вывод?». Это означает, что любые найденные ошибки находятся в «где-то в этой огромной куче кода».

Конечно, вы можете попросить разработчика сидеть с отладчиком и точно определить, где возникла проблема, и поработать над ее исправлением. Это требует много ресурсов и является плохим использованием времени разработчика. Представьте себе, что когда-либо незначительная ошибка, которая у вас есть, приводит к тому, что разработчику необходимо снова отлаживать всю программу.

Решение: множество небольших тестов, каждый из которых указывает на один конкретный потенциальный сбой.

Эти небольшие тесты (например, модульные тесты) имеют преимущество проверки конкретной области кодовой базы и помогают находить ошибки в ограниченном объеме. Это не только ускоряет отладку при сбое теста, но также означает, что если все ваши маленькие тесты не пройдут - вы сможете легче найти сбой в ваших больших тестах (т. Е. Если это не определенная проверенная функция, она должна быть во взаимодействии). между ними).

Как должно быть ясно, создание меньших тестов означает, что ваша кодовая база должна быть разбита на более мелкие тестируемые порции. Способ сделать это на большой коммерческой базе кода часто приводит к тому, что код выглядит так, как вы работаете.

Просто как примечание: это не значит, что люди не зайдут «слишком далеко». Но есть законная причина для разделения кодовых баз на меньшие / меньшие связанные части - если сделано разумно.

Bilkokuya
источник
5
Хотя ваш ответ касается только тестирования и тестируемости, это самая важная проблема, которую некоторые другие ответы полностью игнорировали, поэтому +1.
скомиса
17

Пожалуйста, объясните мне, зачем нам этот стиль DDD, много паттернов?

Многие (большинство ...) из нас действительно не нуждаются в них. Теоретики и очень продвинутые, опытные программисты пишут книги о теориях и методологиях в результате большого количества исследований и их глубокого опыта - это не означает, что все, что они пишут, применимо к каждому программисту в их повседневной практике.

Будучи начинающим разработчиком, полезно читать такие книги, как та, о которой вы упомянули, чтобы расширить ваши перспективы и дать вам знать о некоторых проблемах. Это также избавит вас от смущения и замешательства, когда ваши старшие коллеги используют терминологию, с которой вы не знакомы. Если вы находите что-то очень сложное и, кажется, не имеете смысла или кажетесь полезным, не убивайте себя из-за этого - просто запишите это в голову, что есть такая концепция или подход.

В вашем повседневном развитии, если вы не академик, ваша задача - находить работоспособные, поддерживаемые решения. Если идеи, которые вы найдете в книге, не помогут вам достичь этой цели, не беспокойтесь об этом прямо сейчас, если ваша работа считается удовлетворительной.

Может наступить время, когда вы обнаружите, что можете использовать кое-что из того, о чем читали, но сначала не совсем «получили», а может и нет.

Вектор
источник
12
Хотя на чистом уровне это правильно, это звучит как DDD, а другие паттерны - просто теория. Это не так. Они являются важными инструментами для создания удобочитаемого и поддерживаемого кода.
Йенс Шаудер
9
@PeteKirkham дилемма OPs заключается в чрезмерном использовании шаблонов проектирования. Вам действительно нужен AccountServiceFacadeInjectResolver(реальный пример, который я только что нашел в системе на работе) - ответ, скорее всего, нет.
Викингстеве
4
@vikingsteve OP - не гуру программирования, комментирующий общее чрезмерное использование шаблонов проектирования. ОП - ученик и думает, что они чрезмерно используются в его магазине . Я знаю, что новичок-я думал бы то же самое о коде, который я пишу в настоящее время, но у новичка-меня было много неудачных личных проектов, потому что они оказались слишком запутанными.
Р. Шмитц
3
@ R.Schmitz Тем не менее, у меня с самого начала было множество личных проектов, которые провалились, потому что они слишком старались сделать вещи хорошо спроектированными, организованными, структурированными, ООП ... Все это инструменты. Их нужно понимать и использовать правильно, и вы вряд ли можете обвинить молот в том, что он плохо закручивает. Удивительно, но для понимания этой простой вещи требуется много понимания и опыта :)
Luaan
3
@Luaan Если бы вы уже заботились о хорошо спроектированной, организованной, структурированной ООП, я бы вряд ли назвал вас новичком, но да, злоупотребление - это плохо. Однако вопрос скорее в том, как ОП не понимает, какие проблемы решают эти проблемы. Если вы не знаете причину, кажется, что нет никакой причины - но на самом деле, вы просто еще не знаете ее.
Р. Шмитц
8

Поскольку ваш вопрос охватывает много вопросов и предположений, я выделю тему вашего вопроса:

Зачем нам нужно так много классов в шаблонах проектирования

Мы - нет. Не существует общепринятого правила, согласно которому в шаблонах проектирования должно быть много классов.

Есть два ключевых руководства для того, чтобы решить, куда поместить код и как разбить ваши задачи на разные блоки кода:

  • Сплоченность: любая единица кода (будь то пакет, файл, класс или метод) должна принадлежать друг другу . То есть любой конкретный метод должен иметь одну задачу и делать это хорошо. Любой класс должен отвечать за одну большую тему (что бы это ни было). Мы хотим высокой сплоченности.
  • Связь: любые две единицы кода должны как можно меньше зависеть друг от друга - особенно не должно быть циклических зависимостей. Мы хотим низкого сцепления.

Почему эти два должны быть важными?

  • Сплоченность: метод, который делает много вещей (например, старомодный скрипт CGI, который делает GUI, логику, доступ к БД и т. Д. В одном длинном беспорядке кода) становится громоздким. На момент написания статьи заманчиво было бы просто перевести ваш ход мыслей в долгий метод. Это работает, это легко представить и тому подобное, и с этим можно покончить. Проблема возникает позже: через несколько месяцев вы можете забыть, что вы сделали. Строка кода вверху может находиться на расстоянии нескольких экранов от строки внизу; легко забыть все детали. Любое изменение в любом месте метода может нарушить любое поведение сложной вещи. Реорганизовать или повторно использовать части метода будет довольно обременительно. И так далее.
  • Сопряжение: каждый раз, когда вы меняете единицу кода, вы потенциально можете сломать все другие блоки, которые зависят от нее. В строгих языках, таких как Java, вы можете получить подсказки во время компиляции (то есть о параметрах, объявленных исключениях и т. Д.). Но многие изменения не вызывают такие (то есть изменения поведения), и другие, более динамичные языки, не имеют таких возможностей. Чем выше связь, тем сложнее что-либо изменить, и вы можете остановиться, где полная перезапись необходима для достижения какой-то цели.

Эти два аспекта являются базовыми «драйверами» для любого выбора «куда поместить» на любом языке программирования и любой парадигме (не только ОО). Не все точно знают о них, и требуется время, часто годы, чтобы по-настоящему понять, как они влияют на программное обеспечение.

Очевидно, что эти две концепции ничего не говорят вам о том, что на самом деле делать . Некоторые люди ошибаются на стороне слишком много, другие на стороне слишком мало. Некоторые языки (глядя на вас здесь, Java) имеют тенденцию отдавать предпочтение многим классам из-за чрезвычайно статичной и педантичной природы самого языка (это не утверждение о значении, а то, чем оно является). Это становится особенно заметно, когда вы сравниваете его с динамическими и более выразительными языками, например Ruby.

Другой аспект заключается в том, что некоторые люди поддерживают гибкий подход, заключающийся в написании кода, который необходим прямо сейчас , и в значительной степени при необходимости, в последующем. В этом стиле разработки вы не создали бы, interfaceкогда у вас есть только один реализующий класс. Вы бы просто реализовали конкретный класс. Если позже вам понадобится второй класс, вы будете проводить рефакторинг.

Некоторые люди просто так не работают. Они создают интерфейсы (или, в более общем случае, абстрактные базовые классы) для всего, что когда-либо могло бы использоваться более широко; это приводит к взрыву класса быстро.

Опять же, есть аргументы за и против, и не важно, какой я или вы предпочитаете. В своей жизни в качестве разработчика программного обеспечения вы столкнетесь со всеми крайностями, начиная от длинных методов спагетти, заканчивая просвещенными, достаточно большими проектами классов, до невероятно взорванных схем классов, которые сильно перегружены. По мере того, как вы становитесь более опытным, вы будете все больше превращаться в «архитектурных» ролей и сможете начать влиять на это в том направлении, в котором хотите. Вы найдете золотую середину для себя, и вы все равно обнаружите, что многие люди не согласятся с вами, что бы вы ни делали.

Следовательно, сохранение открытости является самым важным моментом, и это был бы мой основной совет для вас, поскольку вы, кажется, испытываете большую боль по этому вопросу, судя по остальной части вашего вопроса ...

Anoe
источник
7

Опытные программисты узнали:

  • Потому что эти маленькие программы и программы начинают расти, особенно успешные. Те простые шаблоны, которые работали на простом уровне, не масштабируются.
  • Потому что может показаться обременительным добавлять / изменять несколько артефактов для каждого добавления / изменения, но вы знаете, что добавить, и это легко сделать. 3 минуты печатания бьют 3 часа умного кодирования.
  • Множество маленьких классов не "грязно" только потому, что вы не понимаете, почему накладные расходы на самом деле хорошая идея
  • Без знания предметной области «очевидный для меня» код часто загадочен для моих товарищей по команде ... плюс будущее для меня.
  • Знание племен может сделать проекты невероятно трудными для добавления членов команды, чтобы они легко и усердно работали быстро.
  • Именование - это одна из двух трудных проблем в вычислительной технике, которая по-прежнему актуальна, и многие классы и методы часто являются интенсивным упражнением в именовании, которое многие считают большим преимуществом.
Майкл Даррант
источник
5
Но нужны ли накладные расходы? Во многих случаях, которые я вижу, шаблоны проектирования используются слишком часто. Результатом чрезмерной сложности являются повышенные трудности в понимании, обслуживании, тестировании и отладке кода. Когда у вас есть 12 классов и 4 модуля maven вокруг одного простого класса обслуживания (реальный пример, который я только что видел), он быстро становится менее управляемым, чем вы думаете.
Викингстеве
4
@vikingsteve Вы продолжаете ссылаться на один пример некорректной реализации, надеясь, что это докажет, что структурированный код, в общем, является плохой идеей. Это просто не отслеживается.
MetaFight
2
@MetaFight OP не говорит о структурном коде. Он говорит о том, что он видит как слишком много абстракций. Я утверждаю, что если у вас слишком много абстракций, вы быстро получите очень очень неструктурированный код и множество практически идентичных фрагментов просто потому, что люди не могут справиться с количеством вещей, с которыми им приходится иметь дело.
уточнение
4
@Clearer Я уверен, что все здесь согласны с тем, что гипотетическое неправильное применение структурированного кода - это плохо. ОП говорит, что они младшие. Вот почему люди предполагают, что он / она не знаком с преимуществами структурированного кода и повторяют их.
MetaFight
2

Ответы до сих пор, все они хорошие, начав с разумного предположения, что спрашивающий упускает что-то, что он также признает. Также возможно, что спрашивающий в основном прав, и стоит обсудить, как эта ситуация может возникнуть.

Опыт и практика очень важны, и если пожилые люди приобрели свой опыт в больших и сложных проектах, где единственный способ держать вещи под контролем - с помощью множества элементов EntityTransformationServiceImpl, то они быстро и комфортно воспринимают шаблоны проектирования и строго придерживаются DDD. Они были бы намного менее эффективными при использовании облегченного подхода даже для небольших программ. Как ни странно, вы должны адаптироваться, и это будет отличным опытом обучения.

Хотя, адаптируясь, вы должны воспринимать это как урок в балансе между глубоким изучением единого подхода и тем, что вы можете заставить его работать где угодно, вместо того, чтобы оставаться универсальным и знать, какие инструменты доступны, не обязательно будучи экспертом в любом из них. Есть преимущества для обоих, и оба необходимы в мире.

Джош Рамбут
источник
-4

Создание большего класса и функциональности в соответствии с использованием будет отличным подходом для решения проблем особым образом, который поможет в будущем решить любые проблемы.

Несколько классов помогают идентифицировать их как основную работу, и любой класс может быть вызван в любое время.

Однако, если у вас много классов и функций с их именами, их легко вызывать и управлять ими. Это называется чистым кодом.

Санджив Чаухан
источник
9
Извините, но что вы говорите?
Дедупликатор
@Deduplicator, давайте возьмем пример в java, если мы проектируем, мы использовали потоки и классы jframes для их наследования. Только из одного класса мы не можем использовать некоторые работы Java для дизайна, поэтому нам нужно сделать больше классов
Санджив Чаухан
2
Этот ответ должен представить идею (ы), которые он намеревается представить на более ясном английском языке. Кажется, что основная идея в ответе состоит в том, что более мелкие классы, каждый с одной четко определенной функциональностью, являются хорошей идеей, но ужасная грамматика делает их практически невозможными для понимания. Также само по себе этого утверждения может быть недостаточно.
Талон