Обсуждение шаблонов (patterns) проектирования, отделено от темы "Литература по патернам проектирования" Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[LE0N]

+1 тоже есть эта книжка.В электронном формате. Но, на мой взгляд, не стоит их использовать. (Архитектура при не правильном использовании станет трудно поддаваемая рефакторингу)
С опытом, к ним придёшь сам. А пока - изобретай велосипеды....

[Влад]

Знать, что такое паттерны проектирования, и представлять себе некоторые самые распространенные (не обязательно все!) паттерны и их применение - полезно, поскольку сберегает время при решении типовых задач проектирования.
Но! - не стоит абсолютизировать оные паттерны и приплетать их к месту и не к месту. Иначе, рискуешь ненароком оказаться в роли господина Журдена, который с превеликим удивлением узнал, что вот уже сорок лет говорит прозой

[trdm]

+1 тоже есть эта книжка.В электронном формате. Но, на мой взгляд, не стоит их использовать. (Архитектура при не правильном использовании станет трудно поддаваемая рефакторингу)
С опытом, к ним придёшь сам. А пока - изобретай велосипеды....

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

[Litkevich Yuriy]

после изучения патернов стало легче понимать чужой код

полностью солидарен.

А насчет того, что Шаблоны (зачем транслит я не понял) проектирования не панацея, дак это с первых страниц книги говорится и еще несколько раз в ней вспоминается в разных главах.

Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.- "Приемы объектно-ориентированного проектирования.

Эта книга хороша в первую очередь примерами из жизни, т.е. какой шаблон в какой программе применялся.

[LE0N]

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

Объём этих "поделок" какой ?
В 99% лучше обойтись делегированием чем теми же синглтонами. Гибкость кода становится лучше в разы.
По поводу фабрик - так не читая про паттерны можно без проблем к ним придти. Ну а про обзерверы и прочую байду вообще речи быть не должно. Самые первые вещи, которые получаются при определённых заданиях.

[Litkevich Yuriy]

лучше обойтись делегированием чем теми же синглтонами

помоему одно с другим как-то не вяжется.

[trdm]

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

Объём этих "поделок" какой ?
В 99% лучше обойтись делегированием чем теми же синглтонами. Гибкость кода становится лучше в разы.
По поводу фабрик - так не читая про паттерны можно без проблем к ним придти. Ну а про обзерверы и прочую байду вообще речи быть не должно. Самые первые вещи, которые получаются при определённых заданиях.

твое фанфаронство уже не развлекает, а раздражает.

[ViGOur]

В 99% лучше обойтись делегированием чем теми же синглтонами.

Приведи код, который может помочь обойтись в 99% случаев без синглтонов.

твое фанфаронство уже не развлекает, а раздражает.

Спокойней нужно быть.

[LE0N]

твое фанфаронство уже не развлекает, а раздражает.

Слив засчитан.

Приведи код, который может помочь обойтись в 99% случаев без синглтонов.

А зачем? У синглтона есть один огромный недостаток - если захотелось заменить класс, который используется на данный момент, нужно менять либо сам синглтон, либо лезть в класс его использующий и заменять точку входа. (Теряется такая важная вещь в ООП как полиморфмизм)
И проектировщик системы не может гарантировать того, что наследование там не нужно на 100%.
Ещё я бы посоветывал почитать про "антипаттерны"....

помоему одно с другим как-то не вяжется.

Почему это не вяжется?
Всё просто - вместо singleton::get_instance(), передавать в тот же конструктор класса, его использующего ссылку на данный объект.
Когда я перестал юзать синглтоны, у меня сильно возросла реюзабельность кода.
На мой взгляд, синглтон - это стремление к функциональному программированию. ООП здесь даже и не пахнет. Всё, что в нём осталось от ООП - это инкапсуляция.

[Litkevich Yuriy]

Почему это не вяжется?
Всё просто - вместо singleton::get_instance(), передавать в тот же конструктор класса, его использующего ссылку на данный объект.

однако делегирование и передача ссылки/указателя не одно и тоже.
Что же касается использования ссылки на объект вместо "Одиночки". Я тоже так пологал, пока не попробовал работать с "Одиночкой".
На практике оказалось удобнее использовать "Одиночку"

Подобная вещь используется и в Qt - QSqlDatabse - подобен "Именованному Одиночке"

[LE0N]

Я тоже так пологал, пока не попробовал работать с "Одиночкой".

А я с ним работал в течение года. Теперь вот плююсь....

[ViGOur]

А зачем? У синглтона есть один огромный недостаток - если захотелось заменить класс, который используется на данный момент, нужно менять либо сам синглтон, либо лезть в класс его использующий и заменять точку входа. (Теряется такая важная вещь в ООП как полиморфмизм)

Думаю если так, тогда что-то у вас не так с планированием!

Например есть у нас классы:

Пример

class CSingleton
{
private:
   CSingleton *m_p;

private:
   CSingleton
   virtual ~CSingleton
   CSingleton( CSingleton &r)
   CSingleton &operator=( CSingleton &r)

public:
   static CSingleton *Init();
   static void destroy();
};

class CSessionManager: public CSingleton
{
   // ...
};

LE0N, может быть я что-то не понимаю, но в каком случае нужно будет и что менять?

Сообщение отредактировал ViGOur - 7.4.2009, 8:42

[LE0N]

LE0N, может быть я что-то не понимаю, но в каком случае нужно будет и что менять?

Ну вот захочу я, например, хранить сессии не в файле, а в БД (общая база в локалке).
А механизм с файлами будет использоваться ещё в одном месте - т.к. функционал сессионМенеджера полностью подходит.
Задача, конечно, притянута за уши, но, я думаю, суть понятна...

[ViGOur]

Это точно, что задача притянута, в приведенной тобой задаче это реализуется таким путем:

class CStore {};
class CStoreFile  : public CStore {};
class CStoreBd   : public CStore {};

В CSessionManager используется указатель на CStore, ну и за счет полиморфизма сохраняется или туда или туда.

[LE0N]

или туда или туда.

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

[ViGOur]

Не совсем понял, что имеется ввиду.