Amazon сообщает мне, что я купил эту книгу в сентябре 2004 года, и с тех пор по какой-то причине потерял ее. Я помню, как важна была эта книга, чтобы понять, как я думал о программном обеспечении. Впервые у меня на самом деле есть слова, чтобы обсудить то, что я делал, и проверенные пути к успеху. Конечно, мы все знаем, что … это не было так хорошо.
В частности, это привело к программированию Cargo Cult . С моей точки зрения, похоже, что многие люди сделали предположение, что их приложение хорошо, потому что оно имеет шаблоны проектирования, а не потому, что шаблоны проектирования приведут к упрощению кода.
Эта книга вышла в 1994 году. И с тех пор в мире программного обеспечения произошли некоторые изменения. В этой серии я собираюсь взглянуть на все эти шаблоны проектирования и посмотреть, как они выдерживают испытание временем. Помните, что шаблоны проектирования были написаны в то время, когда большинство программного обеспечения были однопользовательскими клиентскими приложениями (например, Win Forms, а затем сократились на девять порядков), без Интернета или Интернета, без многопоточности, очень маленькой сети, очень медленных циклов обновления и гораздо медленнее машин. Ни одно из этих предположений не имеет отношения к тому, как мы создаем программное обеспечение сегодня, но они составляют ядро среды, которая была актуальна на момент написания книги. Я думаю, что будет интересно посмотреть, как эти вещи выдержат.
И поскольку я знаю придирки, позвольте мне настроить контекст. Мы говорим о построении шаблонов проектирования в контексте приложения .NET, предназначенного для системного программного обеспечения (например, RavenDB) или корпоративных приложений. Это контекст, в котором я говорю. Приведение аргументов / опций из дополнительных контекстов не имеет отношения к обсуждению.
Я также не собираюсь обсуждать сами паттерны на любой глубине, если вы этого хотите, идите и прочитайте книгу, она все еще очень хорошая, хотя она вышла почти 20 лет назад.
Абстрактная фабричная картина
Суть метода Абстрактной фабрики Pattern заключается в том, чтобы «обеспечить интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов».
Вот пример кода:
static IGUIFactory CreateOsSpecificFactory()
{
string sysType = ConfigurationSettings.AppSettings["OS_TYPE"];
if (sysType == "Win")
{
return new WindowsFactory();
}
else
{
return new MacFactory();
}
}
У меня два мнения об этом шаблоне. С одной стороны, у нас есть довольно убедительные доказательства того, что это было очень плохо для отрасли в целом. Для получения подробной информации, вы можете увидеть пост Почему я ненавижу фреймворки . Когда я впервые увидел это, вскоре после прочтения Go4 в первый раз, я был в слезах от смеха. Но ситуация, которую он описывает, верна, точна и все еще болезненна сегодня.
Например, WCF страдает от чрезмерного использования абстрактных фабрик. Например, IInstanceProvider (и я просто обожаю это для того, чтобы связать это с вами, как правило, нужно реализовать IServiceBehavior).
Как упоминалось в сообщении I Hate Frameworks:
Каждый завод по производству молотков построен для вас лучшими специалистами в области заводов по производству молотков, поэтому вам не нужно беспокоиться обо всех деталях, которые входят в строительство завода.
Круто , или нет, в зависимости от обстоятельств.
Опять же , это является полезной картиной. Проблема состоит в том, что в общем случае создание объектов, которые создают объекты (которые создают еще больше объектов), является довольно хорошим показателем того, что ваша архитектура уже довольно таки замкнута. Вы должны стремиться к архитектуре, которая имеет минимальное количество уровней, и абстрактная фабрика — это совершенно новый уровень даже сам по себе.
Рекомендация: избегайте, если можете. Если вы столкнетесь с тем местом, где, по вашему мнению, это необходимо, подумайте, можете ли вы упростить свою архитектуру до такой степени, когда это не требуется.