2009-08-24 3 views
5

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

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

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

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

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



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

ответ

8

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

+0

@jrista: Я решил оставить заводский класс в пространстве имен Loader. Наличие фабричного метода в родительском пространстве имен, по-видимому, загрязняет структуру проекта. – Sung

+0

Я думаю, что это место.:) Если вы когда-нибудь решите вытащить пространство имен Loader в свою собственную сборку, вы не столкнетесь с проблемами с отсутствующими на заводе ссылками или что-то в этом роде. – jrista

2

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

+0

Насколько я знаю, обычно объект не должен вызывать/создавать экземпляр объекта/метода дочернего пространства имен. Но если бы мне пришлось переместить фабрику в родительское пространство имен, не был бы ли заводский метод единственным доступным классам в дочернем пространстве имен? – Sung

+0

Зачем ты так говоришь. Я не вижу причины, почему объект не может вызывать/создавать экземпляры и метод/объект дочернего пространства имен. Это действительно зависит от того, как вы хотите, чтобы ваш API выглядел снаружи. –

4

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

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

Loader 
- DocumentLoaderFactory 
- DocumentLoadType 
- IDocumentLoader 


Loader\Implementation 
- NameDocumentLoader 
- TypeDocumentLoader 
- ConnectionDocumentLoader 
- DocumentLoader 

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

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

+0

@Odd: Спасибо, Нечетный. Да, DocumentLoader является * абстрактным * классом. И создание другого пространства имен для реализации - это подход, о котором я не думал о – Sung

+0

@Odd: абстрагирование путем введения другого пространства имен действительно звучит солидно, но наличие слишком большого пространства имен в моем случае, похоже, не стоит того, чтобы мой конкретный случай. – Sung

+0

Это нормально, это не подходит всем. Мне лично не нравится держать слишком много классов в одном каталоге namespace /, потому что он загромождает мой код и где я могу логически отделяться, я это делаю. – Odd

Смежные вопросы