Do której przestrzeni nazw należy klasa fabryczna?

Mam klasę fabryki, DocumentLoaderFactory, która po prostu zwraca instancję implementującą interfejs, IDocumentLoader.Do której przestrzeni nazw należy klasa fabryczna?

Wszystko realizacja polega na poniższej nazw

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

Ale co ja zastanawiałem się, co nazw nie DocumentLoaderFactory należeć? Na razie umieściłem klasę fabryczną w obszarze nazw *.Loader, ale jest ona używana z poziomu kontroli użytkownika (ActiveFileWindow) nadrzędnej przestrzeni nazw, Skim.Ssms.AddIn.ActiveFileExplorer, jak pokazano poniżej.

Co by było zaletami & przeciwstawienia metody fabrycznej w obrębie *.Loader lub jej nadrzędnej przestrzeni nazw? Chciałbym podjąć decyzję w zależności od plusów/minusów.

Oto układ mojego projektu alt text

Źródło

2009-08-24 Sung

Powiedziałbym, że najlepiej będzie kolokować swoje fabryki z typem, który tworzą. Fabryka jest dostawcą czegoś i powinna być związana z rzeczami, które zapewnia. Jeśli będziesz przestrzegać zasad spójności, dojdziesz do tego samego wniosku. Powiązane rzeczy powinny być blisko siebie, aby utrzymać spójny interfejs API.

Źródło

2009-08-24 00:30:51 jrista

@jrista: Postanowiłem opuścić klasę fabryczną w przestrzeni * Loader. Posiadanie metody fabryki w nadrzędnej przestrzeni nazw zdaje się zanieczyszczać strukturę projektu. – Sung

Myślę, że to właściwe miejsce.:) Jeśli kiedykolwiek zdecydujesz się wyrzucić przestrzeń nazw Loader do swojego własnego zespołu, nie natrafisz na problemy z brakującymi referencjami fabrycznymi lub cokolwiek w tym stylu. – jrista

powiedziałbym pozostawić go w **. * Ładowarka nazw jak to będzie łatwiej znaleźć podczas pracy z IDocumentLoader implementacje .

Źródło

2009-08-24 00:28:12

O ile mi wiadomo, zwykle obiekt nie powinien wywoływać/tworzyć instancji obiektu/metody podrzędnej przestrzeni nazw. Ale jeśli miałbym przenieść fabrykę do nadrzędnej przestrzeni nazw, czy metoda fabryczna nie byłaby jedyną dostępną do klas wewnątrz podrzędnej przestrzeni nazw? – Sung

Dlaczego tak mówisz? Nie widzę powodu, dla którego obiekt nie może wywoływać/tworzyć instancji i metody/obiektu dziecięcej przestrzeni nazw. To naprawdę zależy od tego, jak chcesz, aby Twój interfejs API wyglądał z zewnątrz. –

Ponieważ kod, który używa twoich fabrycznych potrzeb, nie ma absolutnie żadnej wiedzy na temat implementacji w abstrakcyjnym wzorze fabrycznym, zazwyczaj umieszczam interfejs i fabrykę (plus wszelkie informacje o typie) w katalogu głównym, następnie implementacje w ich własnych folderach (lub folder, jeśli jest ich mało).

Więc w twoim przypadku mam coś takiego:

Loader 
- DocumentLoaderFactory 
- DocumentLoadType 
- IDocumentLoader 


Loader\Implementation 
- NameDocumentLoader 
- TypeDocumentLoader 
- ConnectionDocumentLoader 
- DocumentLoader

mam przyjąć, że DocumentLoader jest abstrakcyjną klasą bazową, która dziedziczy interfejs ze względu na jego nazwisko, ale masz pomysł. Nie wiem, do czego służy inna klasa "TreeViewImageIndex", ale można ją umieścić w dowolnym miejscu lub zupełnie innym, jeśli jest to właściwe.

Dzięki temu Twój kod jest przyjemny i spójny, nie wymaga, aby Twoja klasa implementacji znała przestrzeń nazw Loader \ Implementation i pozwalała na łatwiejsze odczytanie drzewa dokumentu.

Źródło

2009-08-24 01:09:15 Odd

@Odd: Dzięki, Dziwne. Tak, DocumentLoader jest * abstrakcyjną * klasą. I tworzenie innej przestrzeni nazw dla implementacji jest podejściem, którego nie myślałem o – Sung

@Odd: Abstrahowanie przez wprowadzenie innej przestrzeni nazw brzmi solidnie, ale zbyt głęboka przestrzeń nazw w moim przypadku nie wydaje się być warta kłopotów. mój konkretny przypadek. – Sung

To dobrze, nie pasuje do wszystkich. Osobiście nie lubię utrzymywać zbyt wielu klas w jednym katalogu nazw/katalogów, ponieważ powoduje to zaśmiecanie mojego kodu i tam, gdzie mogę logicznie oddzielić, tak robię. – Odd

Do której przestrzeni nazw należy klasa fabryczna?

Odpowiedz

Powiązane problemy