Singleton Factory для синтаксического анализа сообщений

Question

Мы работаем над приложением для обработки различных XML-сообщений и загрузки их в хранилище данных. Один из разработчиков, с которыми я работаю, создал Singleton Factory, используя отражение, чтобы создать экземпляр соответствующего подкласса сообщения. Мой вопрос заключается в том, чтобы использовать одноэлементный завод для фабрики ... (Использование объекта для построения объекта SqlCommand необходимо передать в БД). Завод определенно имеет смысл здесь, в той части, в которой я неясен, используется Singleton в сочетании с Фабрикой.

Я прочитал много сообщений, stackoverlow ответов и т. Д., И мне все еще не ясно, почему для этого сценария мы будем использовать этот шаблон (Singleton с фабрикой ... Я бы предположил, что просто использует заводскую модель?).

Просто пытаясь понять, как я собрал вас, вы бы хотели использовать Singleton, если хотите обеспечить один и только один интерфейс?

Answer 1

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

Заводы, с другой стороны, используются для создания объекта, в котором вы не обязательно знаете точный тип возвращаемого класса. Например, у вас может быть завод, который возвращает автомобильный объект, но точный класс, который возвращается, может быть Volkswagen, или это может быть Ferrari.

Заводы используются для инъекций зависимостей (DI). Таким образом, в примере, который вы даете, вы можете использовать фабрику для возврата объекта, который взаимодействует с БД, но фактический класс может взаимодействовать с БД с помощью операторов SQL или, возможно, это другой класс, который использует инфраструктуру объектно-реляционного сопоставления (ORM) , Это отделяет фактический интерфейс/реализацию базы данных от остальной части приложения и обеспечивает большую гибкость в изменении доступа к БД в будущем. Завод может даже вернуть макет доступа к БД, который можно использовать для модульного тестирования. DI можно использовать для изменения того, какой метод используется во время выполнения. Я бы окончательно рекомендовал использовать Фабрики по этим причинам.

Заводы могут также возвращать одноточие. Таким образом, вопрос, который нужно задать при определении того, нужен ли вам один сингл, заключается в необходимости поддерживать состояние в приложении для всех объектов, которые будут получать к нему доступ. Примером того, что вы хотите сохранить состояние, является то, что вы хотите, чтобы соединение открывалось для базы данных для любого объекта, который обращается к этому объекту БД на весь срок службы приложения. Не предлагая вам это сделать, но это всего лишь пример того, почему вы, возможно, захотите сохранить информацию о состоянии этого объекта в течение всего срока службы приложения.