Зачем нам нужен абстрактный шаблон дизайна фабрики?

Абстрактные фабрики отлично подходят для поддержки нескольких платформ, сохраняя при этом унифицированную кодовую базу. Предположим, у вас есть большая программа на Qt или GTK + или .NET / Mono, которую вы хотите запустить в Windows, Linux и OSX. Но у вас есть функция, которая реализуется по-разному на каждой платформе (возможно, через API-интерфейс kernel32 или POSIX).

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

С помощью этой абстрактной фабрики вашему интерфейсу не нужно ничего знать о текущей платформе.

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);

Это все о зависимостях. Если вам не нужны тесные связи и зависимости, вам не нужна абстрактная фабрика. Но это будет иметь значение, как только вы напишите приложение, которое нуждается в обслуживании.

Если ответить прямо на ваш вопрос, вы, вероятно, сможете обойтись без использования такого шаблона проектирования.

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

По моему собственному опыту, большую часть времени реализуется Factory, и по мере роста проекта он превращается в более сложные шаблоны проектирования, такие как Абстрактная Factory.

Реальный пример использования шаблона «Абстрактная фабрика» - это предоставление доступа к данным к двум разным источникам данных (например, к базе данных SQL и XML-файлу). У вас есть два разных класса доступа к данным (шлюз в хранилище данных). Оба наследуются от базового класса, который определяет общие методы, которые должны быть реализованы (например, Load, Save, Delete).

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

Абстрактная фабрика - это очень центральный паттерн проектирования для Dependency Injection (DI). Вот список вопросов Stack Overflow, в которых применение Abstract Factory было принято в качестве решения.

Насколько я понимаю, эти вопросы представляют реальные проблемы, с которыми сталкивались люди, так что это поможет вам начать с реальных примеров:

• Есть ли паттерн для инициализации объектов, созданных через DI контейнер
• Невозможно совместить Factory / DI
• WCF Dependency injection и абстрактная фабрика
• Как настроить IoC, когда ключевому классу нужна Session (или другая контекстно-специфическая переменная)
• Как разрешить тип на основе значения конфигурации конечного пользователя?
• Паттерн стратегии и инъекция зависимостей с помощью Unity
• Абстрактный паттерн фабрики поверх IoC?
• Правильно ли использовать и тестировать класс, использующий паттерн фабрики?
• Книга DDD, Эрик Эванс: Пожалуйста, объясните, что имеется в виду под "FACTORY должна быть абстрагирована до желаемого типа, а не до конкретного создаваемого класса (классов)."
• DI контейнер, фабрика или new для эфемерных объектов?
• Как протестировать создание экземпляра?
• Какова наилучшая стратегия для Dependency Injection пользовательского ввода?

Если я правильно вас понял, вопрос в том, почему у нас есть и метод Factory, и паттерн абстрактной фабрики. Абстрактная фабрика нужна, когда разные полиморфные классы имеют разные процедуры инстанцирования. И вы хотите, чтобы какой-то модуль создавал экземпляры и использовал их, не зная никаких деталей инициализации объекта. Например, вы хотите создать Java-объекты, выполняющие некоторые вычисления. Но некоторые из них являются частью приложения, а байткод других должен быть прочитан из БД. С другой стороны - зачем нам нужен метод фабрики? Согласитесь, что абстрактная фабрика перекрывает его. Но в некоторых случаях - это гораздо меньше кода для написания, меньше классов и интерфейсов делает систему проще для понимания.

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

Я считаю, что самый пифонический способ борьбы с «записями» - это просто... словари ! Класс - это своего рода словарь стероидов.

Пример класса data по существу является способом преобразования словаря в класс.

(На боковой ноте, я бы предпочел использовать self. __ setattr __ (имя, kw [имя]) .)

Ну, это нормально. Метод Receive () не вернется, пока сервер не отправит что-то другое. Что он, вероятно, не сделает в вашем случае, пока вы не попросите его отправить что-то еще первым. Вызов Receive () следует выполнить только в том случае, если не получен полный ответ сервера.

Проверьте спецификацию протокола. Обычно сервер отправляет то, что позволяет сообщить, что получен полный ответ. Как и количество байтов в сообщении. Или специальный символ в конце сообщения. Популярностью пользуется Linefeed (vbLf).

Я нахожу образец абстрактной фабрики переоцененным.

Во-первых, не происходит , что часто у вас есть набор взаимосвязанных типов, которые вы хотите создать.

Во-вторых, уровень косвенности (абстракции), обеспечиваемый интерфейсами , обычно достаточен при работе с инъекцией зависимостей.

Типичный пример по сравнению с MacGui и MacGui против... , где часто проще реализовать, определяя конкретные кнопки, полосы прокрутки и т.д. с помощью образца Visitor и/или Interpreter для обеспечения фактического поведения.

просто, представляя, что у вас есть код, который работает с абстракцией, вы должны создавать абстракции, а не конкретные классы.

Вы всегда должны работать с абстракциями, потому что вы можете лучше модифицировать код.

Вот хороший пример: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23

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