Обсуждение паттернов проектирования

[][tiger]

Если FAQ по .NET по интеренету целая куча - один другого лучше, то живого обсуждения применения паттернов проектирования я в русскоязычном интернете до сих пор не встречал.

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

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

 

[karlito]

Я тоже за.

Вот ты ][tiger и начни

 

[Dr.Gigabit]

Идея хорошая, не одного тебя она посещает Но вот как и с чего начать - лично у меня четкого представления нет. Уж очень обширная тема.

Может быть через месяц-другой созрею расказать что-нибудь о DSL и Software Factories

 

[Guest]

У меня сложилось такое впечатление что использование паттернов имеет смысл только в крупных проектах... скажем так от 20-30 программистов. А таких проектов я не видел. И не думаю, что они часто бывают на русскоязычных просторах.

 

[karlito]

У меня сложилось такое впечатление что использование паттернов имеет смысл только в крупных проектах... скажем так от 20-30 программистов. А таких проектов я не видел. И не думаю, что они часто бывают на русскоязычных просторах.

Чушь. Ты, наверное, не совсем понимаешь философию паттернов проектирования. В двух словах, это некие решения проблем, с которыми кто-то когда-то сталкивался.

Допустим, берём простой шаблон Prototype (копирование объектов). Если будешь создавать копирование объектов сам, не зная как кто-то решал эту проблему, то наткнёшься на грабли, на которые до тебя натыкались многие программисты. А паттерн предосталяет тебе некий шаблон решения данной проблемы, которая может решить твою проблему или часть проблемы.
И не надо изобретать второй раз колеса. В Prototype ясно сказано, что чтобы не столкнуться с проблемой расширения классов используйте "защищённый конструктор".

Насчёт крупных проектов. Ты тоже ошибаешься.

 

[Stanly]

Вот я сейчас начал делать подсистему логирования различных событий. Нужно логировать печать на принтере (кто, когда и что печатал). Решил для начала сделать лог в файл, но потом буду расширять что бы и в БД писало. Так же была идея сделать как можно универсальнее механиз логирования. Так например хотелось бы логировать не только события печати на принтере, но и какие-н другие события. Так вот я решил использовать паттерн абстактная фабрика для создания экземпляров логгеров (объектов которые пишут в лог). Тут меня начали мучить сомнения что нужно сделать фабрику фабрик логеров, т.е. процесс будет построен так: сначала у фабрики фабрики логгеров спрашиваем экземпляр фабрики определенного типа логерров (допустим фабрики логеров печати), потом у этой фабрики спрашиваем конкретные объекты (логгер, который работает с файлом или с БД). Так вом мне кажется что что-то в этой схеме не так.

 

[karlito]

Вот я сейчас начал делать подсистему логирования различных событий. Нужно логировать печать на принтере (кто, когда и что печатал). Решил для начала сделать лог в файл, но потом буду расширять что бы и в БД писало. Так же была идея сделать как можно универсальнее механиз логирования. Так например хотелось бы логировать не только события печати на принтере, но и какие-н другие события. Так вот я решил использовать паттерн абстактная фабрика для создания экземпляров логгеров (объектов которые пишут в лог). Тут меня начали мучить сомнения что нужно сделать фабрику фабрик логеров, т.е. процесс будет построен так: сначала у фабрики фабрики логгеров спрашиваем экземпляр фабрики определенного типа логерров (допустим фабрики логеров печати), потом у этой фабрики спрашиваем конкретные объекты (логгер, который работает с файлом или с БД). Так вом мне кажется что что-то в этой схеме не так.

Здесь скорее не фабрику фабрик надо, а Factory Method для создания фабрики. Обычно в этом методе я читаю из конфига, какую фабрику хотят создать и через рефлексию создаю.

	internal static DomainObjectFactory Current
{
get
{
CommonCacheManager<DomainObjectFactory> cache = CommonCacheManager<DomainObjectFactory>.GetManager();
string cacheKey = "DomainObjectFactory";
DomainObjectFactory factory = cache[cacheKey] as DomainObjectFactory;
if(factory == null)
{
string typeName = CurrentContext.DomainObjectFactory;
Type type = Type.GetType(typeName, true);

if(type == typeof(DomainObjectFactory))
{
factory = new DomainObjectFactory();
}
else
{
factory = Activator.CreateInstance(type) as DomainObjectFactory;
if(factory == null)
throw new MSApplicationException("DomainObjectFactory cannot be created.");
}

cache.Add(factory, cacheKey);
}

return factory;
}
}

 

[Stanly]

Здесь скорее не фабрику фабрик надо, а Factory Method для создания фабрики. Обычно в этом методе я читаю из конфига, какую фабрику хотят создать и через рефлексию создаю.

	internal static DomainObjectFactory Current
{
get
{
CommonCacheManager<DomainObjectFactory> cache = CommonCacheManager<DomainObjectFactory>.GetManager();
string cacheKey = "DomainObjectFactory";
DomainObjectFactory factory = cache[cacheKey] as DomainObjectFactory;
if(factory == null)
{
string typeName = CurrentContext.DomainObjectFactory;
Type type = Type.GetType(typeName, true);

if(type == typeof(DomainObjectFactory))
{
factory = new DomainObjectFactory();
}
else
{
factory = Activator.CreateInstance(type) as DomainObjectFactory;
if(factory == null)
throw new MSApplicationException("DomainObjectFactory cannot be created.");
}

cache.Add(factory, cacheKey);
}

return factory;
}
}

В данном случае скорее всего или даже точно потребуется использовать несколько фабрик фабрик, т.к. они у меня создают объекты, которые выполняют разные по смыслу действия(логируют использование принтера, логируют какие-то другие события в системе). У вас фабрики являются взамозаменяемыми.
P. S. Я только начал разбираться с патерними.