есть такой код на С++:


товарищ, который его мне привёл, утверждает, что он (код) реализует паттерн проектирования "Фабрика" (ну или как-то так, за название не ручаюсь =))

я тут вижу весьма эээ... слабую расширяемость этого паттерна/кода (кто не видит, попробуйте унаследовать от CFigure ещё один клас и создать его экземпляр фабрикой не меняя при этом сорцы CFactory и geom_obj::type)

у каково ваше мнение на счёт паттернов? зло или благо? как бы вы реализовали этот паттерн (с устранением того недостатка расширяемости, что я указал) на вашем любимом ЯП?

Добавлено @ 20:42
да, я сам реализовывал аналоги на Scheme (их было несколько), без использования всяких готовых ООП-систем как в PLT Scheme, их было несколько и вдаваться в подробности я не стану, тем более, что Scheme использует динамическую типизацию, а С++ статическую, однако приведу код на Object Pascal (другого) товарища, который (код) реализует ту же функциональность, но лишён недостатка расширяемости:


Это сообщение отредактировал(а) k0rvin - 15.7.2010, 20:52

k0rvin, это абстрактная фабрика, aka виртуальный конструктор. Погуглите.

Насчет реализации на С++  - почитайте Александреску, там есть более удобная реализация.

как бы в Object Pascal виртуальный конструктор "из каробки" и лишён ограничений расширяемости, присутствующем в приведённом мной коде на С++.

если Вам не сложно, скопипастите пример Александреску сюда.

Да, это фабрика. Однако как Вы правильно указали, реализация в таком виде не позволяет использовать преимущества паттерна. 

Когда в реализации этого паттерна наблюдается куча if...then...else или switch, реализацию клеймят как нубскую. Почитайте, например, здесь. Там же есть варианты ненубской реализации. Ваш код на Delphi тоже ничего.

Добавлено через 1 минуту и 2 секунды

Абстрактная фабрика и фабрика - разные паттерны проектирования. Скажем, у GoF последний даже не описан.

ясно, спс за разъяснения, я так и думал, что "что-то не так" в этом коде =)

а код на паскале не мой =)

Добавлено через 2 минуты и 50 секунд
kemiisto,

может выскажетесь относительно "паттернов проектирования -- благо или зло?", как вопрос поставлен в топике (описании топика)? ради этого затевался топик в общем-то, любопытно Ваше мнение.

1) Если программист не пользуется шаблонами проектирования, то его код никому нафиг не нужен, по крайней мере мне, как руководителю отдела, точно. Изучать устройство "нового велосипеда" написанного под воздействием каких-то грибов - долго и дорого для проекта. Заменяемость человека практически никакая. 
2) Шаблоны проектирования это не только общепринятые приемы. Да общепринятыми они стали не из-за того чтоб просто сделать что-то общепринятым  Это достаточно хорошо продуманные реализации часто встречаемых задач в архитектуре программного обеспечения. Как бонус, многие только после знакомства с шаблонами начинают въезжать в ООП. Потому как писать объектно-ориентированные программы и пользоваться классами это совершенно две разные концепции в программировании . Я не раз видел как люди слонов наследовали от автомобиля только для того чтоб поместить его в гараж.

Это сообщение отредактировал(а) Mephisto - 16.7.2010, 09:01

Ни то, ни другое.

1) Начать надо вот с чего. Обычно, когда речь идёт о паттернах проектирования, подразумеваются оные, описанные у GoF. И некоторые другие в книгу не вошедшие. Сразу надо отметить, что эти паттерны имеет смысл использовать только в императивных языках со строгой статической типизацией. Наример, Java. Посмотрите, как много примеров GoF-паттернов практически в чистом виде можно обнаружить в стандартных библиотеках этой платформы.

Но если мы используем функциональный ЯП паттерны будут совсем иные. Если гибридный ЯП (Scala, например) - опять-таки свой набор паттернов.

2) Паттерны - суть есть шаблонные решения. В чистом виде встречаются редко. И даже более того... Вот Mephisto отметил выше, что изучение паттернов (он имел ввиду GoF-паттерны) позволяет понять ООП. Верно. Но можно пойти и другой дорогой. Не знать никаких паттернов, а знать пару-тройку правил "хорошего" ООП. Скажем, по возможности наследованию предпочитать композицию, писать как можно более несвязанные классы, разрешать объектам общаться только посредством передачи сообщения, ... В итоге код будет содержать решения близкие по архитектуре к паттернам. 
 ©

3) По большому счёта паттерны/антипаттерны - просто очень хорошо изученные и систематизированные примеры, показывающие, что такое хорошо и что такое плохо. Поэтому знать надо, но слепо и бездумно использовать везде и всегда - увольте. У любого шаблонного решения есть недостатки. Именно потому, что оно шаблонное. Специфика конкретной задачи может столько ярко обножить эти недостатки, что лучше паттерн и вовсе не использовать. А написать что-то близкое по смыслу, но лишённое того недостатка.

Это сообщение отредактировал(а) kemiisto - 16.7.2010, 09:40

с этим я полностью согласен. черт, даже припоминаю, что в SICP когда описывалась объектная декомпозиция, использовался некий паттерн, хз как называется (если есть название):


kemiisto
спс за ответ. а не подскажете есть ли какая русскоязычная статья, где анализируются методы реализации наследования и/или сама концепция наследование вообще, а то я в последнее время часто натыкаюсь на высказывания, что наследование (по крайней мере в том виде, в котором оно реализовано в некоторых популярных языках) не нужно / "не правильно", вот и Вы пишете "по возможности наследованию предпочитать композицию"...

Дык у GoF по сути вся первая глава. Конкретно 1.6 Как решать задачи проектирования с помощью паттернов, после заголовка "Механизмы повторного использования" идёт обсуждение.

На стр.35 вторым правилом объектно-ориентированного проектирования курсивом декламируется: 


P.S. Вообще, по ООП (пускай и применимок проектированию ОС) есть одна зачётная диссертация. Но на английском. Сам сейчас читаю.  

шрифт там ужасен... английский, к сожалению недостаточно знаю, буду читать GoF =/

Если вообще об объектно-ориентированном программировании, то вот это хорошая книга.
А если конкретно рассматривать наследование, то 

хороший совет, но требует уже достаточного высокого понимания концепции. Жить с таким принципом не так легко, иногда это приводит к ненужному усложнению, по сему нужно четко понимать когда все-таки лучше наследование, а когда агрегация.
Для начала я бы дал совет проверять себя следующим образом:
Когда один класс наследуешь от другого нужно делать следующую проверку: вставлять между словами слово "это". Например: Опель это автомобиль, слон это животное, чайка это птица.
Наследовать один класс от другого можно в том случае, когда ответ однозначно утвердительный.
Если взять мой же пример из предыдущего поста, со слоном, то может получится следующая ситуация:
Наследуем слона от автомобиля чтобы воткнуть в гараж. Получаем "слон это автомобиль = неправда". 
Почему это плохо? Потому что может возникнуть ситуация когда тебе нужно будет пересчитать автомобили на проезжей части, если у тебя по проезжей части будет идти слон, то количество автомобилей получишь в результате больше на единицу.
Если все-таки возникает задача поместить слона в гараж, а гараж только и принимает что автомобили, то следует не слона наследовать от автомобиля, что приведет к ошибке, а перепроектировать класс гаража чтоб он мог поместить и автомобили и слонов.

а как так вариант, напирмер:

?

k0rvin, в LISP'ах я не в зуб ногой. 

Но, вроде как, это примеси. Недостатков множественного наследования тут нет, но есть другие ограничения. Но это несколько иная история...

k0rvin, можно, если класс can-be-in-garage имеет смысл помимо этого. 
Я бы вводил интерфейс а ля:

Такие объекты можно помещать в гараж, при этом можно подсчитать сколько штук, зная габариты. При этом при помещении в гараж можно сразу проверить не больше ли значение Height высоты ворот и прочее.

Добавлено через 1 минуту и 39 секунд
Потому как в один гараж можно помещать автомобили, но камаз, хоть и автомобиль не в каждый гараж по своим габаритам влазит.

не, судя по  это определённо не примеси, ибо все классы в моём примере -- обычные, способные порождать объекты. хотя если ориентироваться на эту цитату из статьи:

то да.

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

Это сообщение отредактировал(а) k0rvin - 20.7.2010, 18:49