Критически о шаблонах проектирования в применении к Java

21 Июл
2012

Чего великого можно ожидать от концепции, основанной на обобщении как бы «best practices» программирования на весьма далёком от идеала языке С++ — внутренне противоречивом: основанном на двух взаимопротиворечивых концепциях — повторного использования исходного кода (инклуды) и повторного использования скомпилированного кода (классы), которая кроме того на год старше, чем Java 1.0 и JavaScript, на два года страше, чем Java 1.1, на 4 года старше, чем Java 2, в которой итератор входит в базовую библиотеку, на полгода старше, чем первый Visual Basic позволяющий писать классы, на два года старше, чем первый Visual Basic, реализующий компонентную модель и на полтора года старше, чем VBScript?

Касательно эпохи и обстоятельств появления книги «Design Patterns: Elements of Reusable Object-Oriented Software», на ум приходят и другие характерные примеры из книжек того времени типа «как правильно программировать на С++», в случае с Java совершенно бесполезные: Java просто физически не позволяет программировать «неправильно» в терминах этих книжек и этих примеров.

Собственно, реально «шаблонов проектирования» там, на мой сегодняшний взгляд, только четыре с половиной — «композит», т.е. на современном языке, «дерево», «запоминание и вспоминание состояния», «цепь отвечания на командные объекты и тоссинга командных объектов» (ветви и циклы допустимы) и «конечный автомат с переходами между состояниями» (стандартный шаблон проектирования для первичных парсеров–токенизаторов).

Остальное — wokaround против отсутствия в относительно «низкоуровневых» языках более «высокоуровневых» опций, в первую очередь и в основном function as first–class object, или просто грамотная системная композиция и декомпозиция — в основном, использование принципа decoupling’а.
По материалам Хабрахабр.



загрузка...

Комментарии:

Наверх