|
|
|
C нами с 25.01.2005
Репутация: 97.3  
|
|
проблемы обычно заключаются в том, чтобы не скатиться к структурному программированию ;)
а решения я вижу в использовании шаблонов проектированя (design patterns)
поэтому в этой теме будем обсуждать шаблоны ;)
(в приложенном файле книга GoF, список скорее всего будет пополняться)
|
Gamma, Helm, Johnson, Vlissides - Design Patterns
design_patterns.zip - 2.01 Mб
Скачиваний: 42
|
|
|
|
|
 |
|
|
|
Возраст: 35  
C нами с 04.02.2005
Репутация: 121.3
|
|
|
Как-то я скептически отношусь к таким книгам. По-моему, под этими шаблонами проектирования пытаются подать и так вполне очевидные вещи, которые просто приходят с опытом и не нуждаются в таком размусоливании и классификации.
|
|
|
|
|
|
|
|
|
|
|
C нами с 15.04.2005
Репутация: 133.2
|
|
|
Проблемы, обычно, заключаются в создании правильно работающего и легко сопровождаемого кода. Паттерны проектирования (обычно используют именно это слово, чтобы не пересекалось с переводом на русский концепции template языка C++) так или иначе используются всеми (независимо от парадигмы, будь то ООП или структурное программирование), другой вопрос — степень осознанности и целесообразности использования. Книга "большой четвёрки" несомненно полезна и интересна, из разряда must read/must have, но достаточно академична.
|
_____________________________
Время не существует, у него нет физического носителя в природе. Его выдумал человек, чтобы измерять скорость.
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.8
|
|
Классифицировать паттерны смысл есть: хотя бы для того, чтобы упростить документирование кода, зачастую достаточно упомянуть название паттерна и какой класс в какой роли выступает вместо подробного описания всего взаимодействия. Книга GoF, это только введение в паттерны, а не их каталог, существует масса распространненых паттернов, не включенных в эту книгу.
PS: а тему стоит переименовать ИМХО, паттерны - это не программирование, а проектирование! Программирование - это процесс их реализации...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39 
C нами с 04.05.2006
Репутация: 63.9
|
|
Объясните плз в двух словах, что подразумевается под этим красивым названием Disign Patterns? Последнее время все чаще и чаще встречаю это словосочетание, но сути понять не могу... 
Пролистав книжку, мне показалось, что это обычные диаграммы классов (Class Diagram) в нотации UML. Или я чето недопонимаю?
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.8
|
|
|
Это не просто диаграммы, это типовые решения. Диаграммы UML - это просто способ их отображения на бумаге вне зависимости от языка программирования. Кстати, там не только диагрммы классов, но и диаграммы взаимодействия (sequence diagrams) должны быть...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| MajorQ писал(а): |
|
Кстати, там не только диагрммы классов, но и диаграммы взаимодействия (sequence diagrams) должны быть...
|
Т.е. на сколько я понимаю design patterns это UML диаграмма классов реализованная в коде, или как? А по поводу взаимиодействия на диаграмме классов оно как раз и показывается... наследование и агрегация итп...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 51
C нами с 01.03.2005
Репутация: 226.6
|
|
Petro, это решение типовых архитектурных проблем.
С проработкой проблем и сложностей - то есть, чем изобретать велосипед и набивать шишки на собственных ошибках, лучше сразу использовать проработанные решения. С UML это мало связано, просто некоторые источники предпочитают демонстрировать design patterns в виде UML-диаграм, но это только средство представления.
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.8
|
|
|
Petro, а последовательность передачи сообщений как на диаграмме классов отобразить? Только Sequence или Colaboration диаграммы! Паттерн - это сама идея, он не зависит от языка. Лишь бы язык был ОО. UML-диаграммы это только способ отображения паттерна на бумаге/экране.
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
Griphon, а чем по сути являются патерны? Шаблонами классов и связей между ними, описанными сигнатурами заголовков классов и методов, но без реализации?
Добавлено спустя 14 минут 45 секунд:
MajorQ, ну по сути под передачей сообщения в самой концепции ООП является вызов метода, разве не так?
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.8
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
Татиана, это же гораздо интереснее!
Кстати к теме не мешало бы вернуться... Есть о чем поговорить, причем говорить можно до бесконечности! )))
Вопрос таков... А для чего нужен ООП, и нужен ли он вообще? 
|
|
|
|
|
|
|
|
|
|
|
C нами с 25.01.2005
Репутация: 97.3
|
|
парадокс ООП
есть фрукты: яблоки, груши и апельсины
есть корзинка, в которой хранятся фрукты
после того, как в корзинку сложены разные фрукты, из нее невозможно достать одни только яблоки ;)
то есть в идеальной ООП клиент видит все объекты в корзинке как фрукты и не может отлечить яблоки от груш ;)
кто знает, как решается?
|
|
|
|
|
|
|
|
|
|
|
Возраст: 51
C нами с 01.03.2005
Репутация: 226.6
|
|
Madlax, а если без аналогий и иносказаний. Что ты имеешь в виду?
Добавлено спустя 33 секунды:
ЗЫ
Может паттерн Visitor?
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.8
|
|
Madlax, типичный контейнер, содержащий объекты, имеющие общего предка. Следовательно, объекты реализуют общий интерфейс фрукт. Зачем тогда их отличать? Либо используй общие методы этого интерфейса (отжать_сок, нарезать_кусочками, очистить_от_кожуры; но не расколоть_скорлупу, ибо это метод для интерфейса орех), либо не складывай в общий контейнер, если уж надо строго разделять. Это не парадокс ООП, это плохая архитектура, неумелое применение концепции ООП.
Есть еще фейк-метод (фейк - потому как он ИМХО "закрывает" иерархию, ограничив количество возможных наследников): использовать виртуальные методы типа bool isApple(), bool isOrange() и т.д. для каждого фрукта. В классе Apple первый будет возвращать true, остальные - false. В Orange, соответсвенно, первый вернет false, второй - true. Но повторюсь, такой метод требует на этапе проектирования базового интерфейса знаний о всех возможных реализациях оного, что не есть гуд...
|
|
|
|
|
|
|
|
| |
|
|
