Поэтому, вероятно, как и многие, я часто сталкиваюсь с головными болями, связанными с проблемами проектирования, в которых, например, есть какой-то шаблон / подход к проектированию, который, кажется, интуитивно подходит к проблеме и имеет желаемые преимущества. Очень часто есть некоторая оговорка, которая затрудняет реализацию шаблона / подхода без какой-либо обработки, которая затем сводит на нет преимущества шаблона / подхода. Я могу очень легко закончить итерацией по многим шаблонам / подходам, потому что, как и ожидалось, почти все они имеют некоторые очень существенные предостережения в реальных ситуациях, в которых просто нет простого решения.
Пример:
Я приведу гипотетический пример, основанный на реальном, с которым я недавно столкнулся. Допустим, я хочу использовать композицию вместо наследования, потому что иерархии наследования препятствовали масштабируемости кода в прошлом. Я мог бы реорганизовать код, но затем обнаружил, что есть некоторые контексты, в которых суперклассу / базовому классу просто нужно вызывать функциональность на подклассе, несмотря на попытки избежать этого.
Следующий наилучший подход, по-видимому, заключается в реализации шаблона половинного делегата / наблюдателя и шаблона половинной композиции, чтобы суперкласс мог делегировать поведение или чтобы подкласс мог наблюдать события суперкласса. Тогда класс становится менее масштабируемым и обслуживаемым, потому что неясно, как его расширять, а также сложно расширять существующие слушатели / делегаты. Кроме того, информация не очень хорошо скрыта, потому что нужно знать реализацию, чтобы понять, как расширить суперкласс (если вы не используете комментарии очень широко).
Поэтому после этого я мог бы просто использовать наблюдателей или делегатов полностью, чтобы избежать недостатков, которые связаны с интенсивным смешением подходов. Однако это имеет свои проблемы. Например, я могу обнаружить, что в конечном итоге мне нужны наблюдатели или делегаты для увеличения количества поведений, пока мне не понадобятся наблюдатели / делегаты практически для каждого поведения. Одним из вариантов может быть просто иметь одного большого слушателя / делегата для всего поведения, но затем реализующий класс заканчивается множеством пустых методов и т. Д.
Тогда я мог бы попробовать другой подход, но с таким же количеством проблем. Затем следующий, и после и т. Д.
Этот итеративный процесс становится очень трудным, когда кажется, что каждый подход имеет столько же проблем, что и любой другой, и приводит к своего рода параличу проектных решений . Также трудно согласиться с тем, что код в конечном итоге будет одинаково проблематичным независимо от того, какой шаблон проектирования или подход используется. Если я окажусь в такой ситуации, значит ли это, что сама проблема нуждается в переосмыслении? Что делают другие, когда сталкиваются с такой ситуацией?
Изменить: Кажется, есть несколько толкований вопроса, которые я хочу прояснить:
- Я полностью исключил ООП, поскольку выясняется, что он на самом деле не является специфическим для ООП, плюс слишком легко неверно истолковать некоторые из комментариев, которые я сделал при прохождении по поводу ООП.
- Некоторые утверждают, что я должен использовать итеративный подход и пробовать разные шаблоны, или что мне следует отказаться от шаблона, когда он перестает работать. Это процесс, на который я собирался ссылаться в первую очередь. Я думал, что это было ясно из примера, но я мог бы сделать это более ясным, поэтому я отредактировал вопрос, чтобы сделать это.