2009-08-24 9 views
5

Tôi có một lớp nhà máy, DocumentLoaderFactory, chỉ đơn giản trả về một cá thể triển khai giao diện, IDocumentLoader.Không gian tên nào thuộc loại nhà máy thuộc về?

Tất cả thực hiện cư trú dưới namespace sau

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

Nhưng những gì tôi đang tự hỏi là, mà không gian tên nào DocumentLoaderFactory thuộc? Tôi đã đặt lớp nhà máy theo không gian tên *.Loader bây giờ, nhưng nó đang được sử dụng từ điều khiển người dùng (ActiveFileWindow) của không gian tên cha, Skim.Ssms.AddIn.ActiveFileExplorer như được hiển thị bên dưới.

Điều gì sẽ được ưu tiên & điểm yếu của việc đặt phương thức nhà máy trong phạm vi *.Loader hoặc không gian tên cha mẹ? Tôi muốn đưa ra quyết định tùy thuộc vào ưu/nhược điểm.



Dưới đây là cách bố trí của dự án của tôi alt text

Trả lời

8

Tôi sẽ nói tốt nhất là định vị nhà máy của bạn với loại mà họ tạo. Một nhà máy là một nhà cung cấp của một cái gì đó, và nên được liên kết và gần gũi với những điều nó cung cấp. Nếu bạn tuân theo các quy tắc của sự gắn kết, thì bạn sẽ đi đến cùng một kết luận. Những thứ có liên quan nên gần nhau để duy trì một API gắn kết.

+0

@jrista: Tôi đã quyết định rời khỏi lớp nhà máy trong * Không gian tên bộ nạp. Việc có phương thức factory trong namespace cha dường như gây ô nhiễm cấu trúc dự án. – Sung

+0

Tôi nghĩ rằng đó là đúng nơi.:) Nếu bạn quyết định kéo không gian tên Loader vào trong assembly riêng của nó, bạn sẽ không gặp vấn đề với nhà máy thiếu tham chiếu hay bất cứ thứ gì tương tự. – jrista

2

tôi sẽ nói lại nó trong **. Loader * namespace vì nó sẽ làm cho nó dễ dàng hơn để tìm thấy khi làm việc với IDocumentLoader bạn triển khai .

+0

Theo như tôi biết, thường là một đối tượng không nên gọi/khởi tạo một đối tượng/phương pháp không gian tên con. Nhưng nếu tôi chuyển nhà máy sang không gian tên cha, thì phương pháp nhà máy có phải là phương thức duy nhất truy cập vào các lớp trong vùng tên con không? – Sung

+0

Tại sao bạn lại nói vậy. Tôi không thấy một lý do tại sao một đối tượng không thể gọi/instantiate và phương thức/đối tượng của một không gian tên con. Nó thực sự phụ thuộc vào cách bạn muốn API của bạn nhìn từ bên ngoài. –

4

Vì mã sử dụng nhu cầu của nhà máy của bạn hoàn toàn không có kiến ​​thức về triển khai trong mẫu nhà máy trừu tượng, tôi thường đặt giao diện và nhà máy (cộng với bất kỳ thông tin loại nào) vào thư mục gốc, sau đó triển khai vào thư mục riêng của chúng (hoặc thư mục nếu có ít).

Vì vậy, trong trường hợp của bạn tôi có cái gì đó như:

Loader 
- DocumentLoaderFactory 
- DocumentLoadType 
- IDocumentLoader 


Loader\Implementation 
- NameDocumentLoader 
- TypeDocumentLoader 
- ConnectionDocumentLoader 
- DocumentLoader 

tôi đã giả định rằng DocumentLoader là một lớp cơ sở trừu tượng mà được thừa hưởng giao diện của bạn vì tên của nó, nhưng bạn sẽ có được ý tưởng. Tôi không biết những gì lớp khác của bạn "TreeViewImageIndex" là cho nhưng bạn có thể đặt nó ở một trong hai nơi hoặc một nơi nào đó hoàn toàn khác nhau nếu nó thích hợp.

Điều này giúp mã của bạn đẹp và gắn kết, không yêu cầu lớp triển khai của bạn biết về không gian tên Loader \ Implementation và cho phép cây tài liệu của bạn dễ đọc hơn.

+0

@Odd: Cảm ơn, Rất tiếc. Có, DocumentLoader là một lớp * abstract *. Và việc tạo một không gian tên khác cho việc triển khai thực hiện là một cách tiếp cận mà tôi chưa nghĩ đến về – Sung

+0

@Odd: Tóm tắt bằng cách giới thiệu một không gian tên khác có vẻ vững chắc nhưng có quá sâu không gian tên trong trường hợp của tôi dường như không đáng để gây rắc rối cho trường hợp cụ thể của tôi. – Sung

+0

Tốt thôi, nó không phù hợp với mọi người. Cá nhân tôi không muốn giữ quá nhiều lớp trong một thư mục/không gian tên duy nhất bởi vì nó làm xáo trộn mã của tôi và nơi tôi có thể tách biệt một cách hợp lý, tôi làm. – Odd