unsorted ~ Объектно-ориентированное программирование

проблемы и решения

C нами с 25.01.2005 Репутация: **97.3**

проблемы обычно заключаются в том, чтобы не скатиться к структурному программированию ;)

а решения я вижу в использовании шаблонов проектированя (design patterns)

поэтому в этой теме будем обсуждать шаблоны ;)

(в приложенном файле книга GoF, список скорее всего будет пополняться)

Возраст: 35 C нами с 04.02.2005 Репутация: **121.3**

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

C нами с 15.04.2005 Репутация: **133.2**

Проблемы, обычно, заключаются в создании правильно работающего и легко сопровождаемого кода. Паттерны проектирования (обычно используют именно это слово, чтобы не пересекалось с переводом на русский концепции template языка C++) так или иначе используются всеми (независимо от парадигмы, будь то ООП или структурное программирование), другой вопрос — степень осознанности и целесообразности использования. Книга "большой четвёрки" несомненно полезна и интересна, из разряда must read/must have, но достаточно академична.

C нами с 09.06.2005 Репутация: **548.7**

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

PS: а тему стоит переименовать ИМХО, паттерны - это не программирование, а проектирование! Программирование - это процесс их реализации...

Возраст: 39 C нами с 04.05.2006 Репутация: **63.9**

Объясните плз в двух словах, что подразумевается под этим красивым названием Disign Patterns? Последнее время все чаще и чаще встречаю это словосочетание, но сути понять не могу... Улыбочка

Пролистав книжку, мне показалось, что это обычные диаграммы классов (Class Diagram) в нотации UML. Или я чето недопонимаю?

C нами с 09.06.2005 Репутация: **548.7**

Это не просто диаграммы, это типовые решения. Диаграммы UML - это просто способ их отображения на бумаге вне зависимости от языка программирования. Кстати, там не только диагрммы классов, но и диаграммы взаимодействия (sequence diagrams) должны быть...

Возраст: 39 C нами с 04.05.2006 Репутация: **63.9**

MajorQ писал(а):

Кстати, там не только диагрммы классов, но и диаграммы взаимодействия (sequence diagrams) должны быть...

Т.е. на сколько я понимаю design patterns это UML диаграмма классов реализованная в коде, или как? А по поводу взаимиодействия на диаграмме классов оно как раз и показывается... наследование и агрегация итп...

Возраст: 50 C нами с 01.03.2005 Репутация: **226.6**

Petro, это решение типовых архитектурных проблем.
С проработкой проблем и сложностей - то есть, чем изобретать велосипед и набивать шишки на собственных ошибках, лучше сразу использовать проработанные решения. С UML это мало связано, просто некоторые источники предпочитают демонстрировать design patterns в виде UML-диаграм, но это только средство представления.

C нами с 09.06.2005 Репутация: **548.7**

Petro, а последовательность передачи сообщений как на диаграмме классов отобразить? Только Sequence или Colaboration диаграммы! Паттерн - это сама идея, он не зависит от языка. Лишь бы язык был ОО. UML-диаграммы это только способ отображения паттерна на бумаге/экране.

Возраст: 39 C нами с 04.05.2006 Репутация: **63.9**

Griphon, а чем по сути являются патерны? Шаблонами классов и связей между ними, описанными сигнатурами заголовков классов и методов, но без реализации?

Добавлено спустя 14 минут 45 секунд:

MajorQ, ну по сути под передачей сообщения в самой концепции ООП является вызов метода, разве не так?

C нами с 09.06.2005 Репутация: **548.7**

Petro, так...

Возраст: 39 C нами с 04.05.2006 Репутация: **63.9**

Татиана, это же гораздо интереснее! Улыбочка

Кстати к теме не мешало бы вернуться... Есть о чем поговорить, причем говорить можно до бесконечности! )))

Вопрос таков... А для чего нужен ООП, и нужен ли он вообще? Сарказм

C нами с 25.01.2005 Репутация: **97.3**

парадокс ООП

есть фрукты: яблоки, груши и апельсины
есть корзинка, в которой хранятся фрукты
после того, как в корзинку сложены разные фрукты, из нее невозможно достать одни только яблоки ;)

то есть в идеальной ООП клиент видит все объекты в корзинке как фрукты и не может отлечить яблоки от груш ;)

кто знает, как решается?

Возраст: 50 C нами с 01.03.2005 Репутация: **226.6**

Madlax, а если без аналогий и иносказаний. Что ты имеешь в виду?

Добавлено спустя 33 секунды:

ЗЫ
Может паттерн Visitor?

C нами с 09.06.2005 Репутация: **548.7**

Madlax, типичный контейнер, содержащий объекты, имеющие общего предка. Следовательно, объекты реализуют общий интерфейс фрукт. Зачем тогда их отличать? Либо используй общие методы этого интерфейса (отжать_сок, нарезать_кусочками, очистить_от_кожуры; но не расколоть_скорлупу, ибо это метод для интерфейса орех), либо не складывай в общий контейнер, если уж надо строго разделять. Это не парадокс ООП, это плохая архитектура, неумелое применение концепции ООП.
Есть еще фейк-метод (фейк - потому как он ИМХО "закрывает" иерархию, ограничив количество возможных наследников): использовать виртуальные методы типа bool isApple(), bool isOrange() и т.д. для каждого фрукта. В классе Apple первый будет возвращать true, остальные - false. В Orange, соответсвенно, первый вернет false, второй - true. Но повторюсь, такой метод требует на этапе проектирования базового интерфейса знаний о всех возможных реализациях оного, что не есть гуд...