К какому пространству имен принадлежит фабричный класс? - PullRequest
Новая
       23

К какому пространству имен принадлежит фабричный класс?

6 голосов
/ 24 августа 2009

У меня есть фабричный класс, DocumentLoaderFactory, который просто возвращает экземпляр, реализующий интерфейс, IDocumentLoader.

Вся реализация находится в следующем пространстве имен

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

Но что мне интересно, какому пространству имен принадлежит DocumentLoaderFactory? Я поместил фабричный класс в пространство имен *.Loader, но он используется из пользовательского элемента управления (ActiveFileWindow) родительского пространства имен Skim.Ssms.AddIn.ActiveFileExplorer, как показано ниже.

Каковы были бы плюсы и минусы размещения фабричного метода в *.Loader или его родительском пространстве имен? Я бы хотел принять решение в зависимости от плюсов / минусов.



Вот макет моего проекта alt text

Ответы [ 3 ]

8 голосов
/ 24 августа 2009

Я бы сказал, что лучше совмещать ваши фабрики с типом (ами), которые они создают. Фабрика является поставщиком чего-либо и должна быть связана с вещами, которые она предоставляет, и быть близкой к ней. Если вы будете следовать правилам сплоченности, то вы придете к такому же выводу. Связанные вещи должны быть близко друг к другу, чтобы поддерживать единый API.

5 голосов
/ 24 августа 2009

Поскольку код, использующий ваши фабричные потребности, абсолютно не знает реализации в шаблоне абстрактной фабрики, я обычно помещаю интерфейс и фабрику (плюс любую информацию о типе) в корень, а затем реализации в свои собственные папки ( или папка, если их мало).

Так что в вашем случае у меня есть что-то вроде: 

Loader
- DocumentLoaderFactory
- DocumentLoadType
- IDocumentLoader


Loader\Implementation
- NameDocumentLoader
- TypeDocumentLoader
- ConnectionDocumentLoader
- DocumentLoader

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

Это делает ваш код красивым и связным, не требует, чтобы ваш реализующий класс знал о пространстве имен Loader \ Practice, и позволяет легче читать дерево документа.

2 голосов
/ 24 августа 2009

Я бы сказал, оставьте его в пространстве имен **. Loader *, так как его будет легче найти при работе с вашими IDocumentLoader реализациями.

...