Нужно ли строго придерживаться шаблона проектирования?

Question

Я сейчас читаю, «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» , автор Эрих Гамма и другие. Я решил сделать несколько небольших проектов, чтобы увидеть реальный результат применения шаблонов проектирования к программному обеспечению, которое я пишу.

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

Answer 1

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

Цель шаблона проектирования - упростить и упростить ваш дизайн. Если он этого не делает, его не стоит использовать.

У других могут быть разные мнения.

Answer 2

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

Это потрясающая книга, классика. Если вы посмотрите на Java или C # SDK, вы увидите, что оба изобилуют примерами (например, Proxy в Java RMI, Decorator во всем пакете java.io, Factory в java.sql и JDBC и т.

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

Answer 3

В дополнение к идее Яна Варли "как это делает мое программное обеспечение лучше?" Из этого утверждения вы можете извлечь следующее: «Уменьшает ли это сложность моего программного обеспечения?» Управление сложностью является ключевым моментом при разработке программного обеспечения, и шаблоны проектирования должны этому способствовать.

Answer 4

Что бы вы ни делали с шаблонами проектирования, вы должны задать себе один простой вопрос: как это улучшит мое программное обеспечение ? Будьте конкретны об этом. Если вы не можете перечислить конкретные преимущества реализации шаблона проектирования в вашей конкретной ситуации, не беспокойтесь; и точно так же, если вы получите «суть» шаблона, вы, вероятно, сможете реализовать его части, полезные для вашей ситуации.

Книга «Шаблоны проектирования» особенно хороша здесь: в ней перечислены конкретные преимущества использования каждого шаблона, а также подробные случаи, когда они уместны, и почему.

Answer 5

Именно поэтому они называются шаблонами, а не алгоритмами или интерфейсами.

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

Answer 6

Стоит ли ... предварительно поддерживать функциональность?

Это зависит от того, как скоро вам понадобится эта функциональность, и от того, абсолютно уверен , что вам она вообще понадобится, но часто ответом будет "нет": Google для термина YAGNI

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

Моя политика и / или политика YAGNI, как правило:

1. Код, что мне нужно сейчас
2. Если позже мне понадобится что-то еще, то повторно и / или измените то, что я написал ранее, возможно, Рефакторинг

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

Answer 7

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