Как проанализировать проблему для соответствия ему подходящим шаблонам разработки?
Я задаюсь вопросом, что должно быть пошаговым подходом анализа к четко определенной проблеме для выяснения возможных Шаблонов разработки, которые могут поместиться в решение.
Руководство можно ли рекомендовать?
спасибо
2 ответа
Любое хранилище паттернов проектирования даст вам подсказки типа "это полезно, когда...", но обычно там нет индексов, которые позволили бы вам искать "номера кредитных карт" и возвращать "объект flyweight". Ближайшее, что можно найти, это, как правило, свободная группировка паттернов как поведенческие, строительные и т.д.
На мой взгляд, нет смысла подходить к проблеме, задаваясь вопросом, какой паттерн проектирования следует применить. Если вы достаточно хорошо знакомы с паттерном, вы сразу заметите, что и как он применяется. Если вы не видите соответствия, то пытаться применить паттерн только для того, чтобы сказать: "Я использовал паттерн XX, поэтому дизайн должен быть хорошим!" - опасная ошибка.
Есть люди, которые даже говорят, что паттерны проектирования - это, прежде всего, ошибка, признак того, что ваш язык недостаточно выразителен. (Это не так безумно, как кажется; вспомните, что такие вещи, как циклы WHILE или хэш-таблицы, когда-то отсутствовали в языках программирования, и мастерам-программистам той эпохи приходилось реализовывать их снова и снова; теперь они являются частью синтаксиса, и никому не приходит в голову называть их "паттернами"). Я не такой экстремист; я думаю, что хорошо подобранный паттерн проектирования может быть очень полезен, когда вы используете его, потому что убеждены, что это хорошее решение, но для этого нужно досконально его понять, а по моему опыту, для этого почти всегда нужно самому попрактиковаться. Ценность паттернов заключается в том, что они дают узнаваемое название чему-то, что часто делается, чтобы вы могли лучше запомнить это и рассказать об этом своим коллегам.
Шаблоны дизайна предназначены для охвата широкого спектра задач по решению проблем. Итак, абстрактно вам нужно иметь способ представить разнообразную выполняемую работу и способ сопоставить шаблон проектирования с этой работой. В целом это «сложно для ИИ».
Конкретным представлением «выполняемой работы», очевидно, является компьютерный исходный код.Теперь проблема сопоставления шаблонов проектирования заключается в сопоставлении с набором фрагментов кода, которые демонстрируют интересующую проблему, и применении «шаблона» (например, решения) как набора шагов, которые изменяют исходный код для достижения желаемого результата.
Средством, которое может выражать такие закономерности и производить автоматические изменения исходного кода, является механизм преобразования программ . Что вы обычно делаете с успешным движком, так это собирать вместе большой набор шаблонов проектирования, создавать их экземпляры как наборы правил перезаписи от исходного кода к исходному, а затем передавать фрагмент кода механизму преобразования, чтобы он мог выполнить шаблон. -соответствие / шаг замены. Самая сложная работа, конечно же, - это кодирование шаблонов проектирования как правил преобразования, поскольку большинство шаблонов проектирования написаны в прозе и имеют тенденцию быть немного нечеткими в отношении точных деталей. (Механизм преобразования программ очень сложно построить, но он, вероятно, уже выполнен :)
Механизмы преобразования программ использовались для реализации рефакторинга (хорошо известный класс шаблонов проектирования), языковых переводов (массовое применение шаблонов проектирования "), а также реструктуризация кода, такая как изменение API-интерфейсов для удовлетворения новых потребностей (один конкретный пример, который я сделал, - это автоматизация преобразования API-интерфейсов кода C ++ в совместимость с CORBA).