Как определить, правильно ли реализован Design Pattern?

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

Концепция Design Patterns сложна и трудна для понимания. Когда реализовано, как определить, является ли реализация правильной, и приложение обладает реальной слабой связью?

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

Желаемые характеристики:

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

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

1. Обратный инжиниринг вашей базы кода для создания нескольких UML-диаграмм.
2. Визуально сравните диаграммы с любым готовым справочником образцов справочного материала.

Это должно дать вам справедливую идею.

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

Шаблоны проектирования

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

1. Они «проверены»: они использовались много раз, и преимущества / недостатки каждого из них общеизвестны, в частности, известны любые тонкие проблемы, которые могут вызвать большие проблемы.
2. Они предоставляют общий набор терминов и, таким образом, облегчают общение. Если кто-то скажет «класс X играет роль наблюдателя в шаблоне наблюдателя», то разработчики, знакомые с шаблоном, могут сразу понять, что происходит.

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

Шаблоны проектирования не «единственно верный путь». Часто вам нужно либо адаптировать их для ваших конкретных целей, либо иногда просто не будет шаблонов, которые соответствуют требованиям. Форсировать шаблон дизайна там, где он не подходит, - плохая идея; это похоже на использование действительно хорошего молотка, когда на самом деле вам нужна отвертка.

Связь

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

В этой статье Википедии перечислены различные типы соединений .

Ответ на самом деле цель, которую вы хотите написать шаблоны проектирования с самого начала. Почему вы хотите гибкость для?

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

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

Шаблоны проектирования сами по себе являются реализацией принципов объектно-ориентированного проектирования. Пока вы будете следовать этим принципам, ваши приложения будут гибкими и масштабируемыми; даже если у вас нет реального шаблона дизайна. Как отметил выше Йоахим Зауэр, это общие решения общих проблем.