Quá nhiều "hậu tố mẫu" - mùi thiết kế?

Question

Tôi chỉ thấy mình đang tạo một lớp có tên là "InstructionBuilderFactoryMapFactory". Đó là 4 "hậu tố mẫu" trên một lớp. Nó ngay lập tức nhắc tôi về điều này:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

Đây có phải là mùi thiết kế không? Tôi có nên áp đặt giới hạn cho số này không?

Tôi biết một số lập trình viên có những quy định tương tự cho những thứ khác (ví dụ không quá N mức độ con trỏ gián tiếp trong C.)

Tất cả các lớp học dường như cần thiết đối với tôi. Tôi có một bản đồ (cố định) từ các dây chuyền đến các nhà máy - thứ mà tôi làm mọi lúc. Danh sách dài và tôi muốn di chuyển nó ra khỏi constructor của lớp có sử dụng các nhà xây dựng (được tạo ra bởi các nhà máy thu được từ bản đồ ...) Và như thường lệ tôi tránh Singletons.

Answer 1

Tôi thấy nó như là một mùi thiết kế - nó sẽ làm cho tôi nghĩ rằng nếu tất cả những mức độ trừu tượng đang kéo đủ trọng lượng.

Tôi không thể thấy lý do bạn muốn đặt tên cho lớp 'InstructionBuilderFactoryMapFactory'? Có các loại nhà máy khác - thứ gì đó không tạo ra một InstructionBuilderFactoryMap không? Hoặc là có bất kỳ loại khác của InstructionBuildersFactories rằng nó cần phải được ánh xạ?

Đây là những câu hỏi mà bạn nên suy nghĩ khi bắt đầu tạo các lớp như thế này. Có thể tổng hợp tất cả các nhà máy sản xuất khác nhau chỉ với một nhà máy và sau đó cung cấp các phương pháp riêng biệt để tạo ra các nhà máy. Cũng có thể chỉ cần đặt những nhà máy sản xuất trong một gói khác và cung cấp cho họ một tên ngắn gọn hơn. Hãy suy nghĩ về những cách khác để làm điều này.

Answer 2

Rất nhiều mẫu trong tên lớp chắc chắn là một mùi, nhưng mùi không phải là chỉ báo rõ ràng. Đó là một tín hiệu để "dừng lại một phút và suy nghĩ lại về thiết kế". Rất nhiều lần khi bạn ngồi lại và nghĩ rằng một giải pháp rõ ràng hơn trở nên rõ ràng. Đôi khi do những hạn chế trong tay (kỹ thuật/thời gian/người đàn ông quyền lực/etc) có nghĩa là mùi nên được bỏ qua cho bây giờ.

Đối với ví dụ cụ thể, tôi không nghĩ rằng đề xuất từ ​​thư viện đậu phộng là một ý tưởng hay nếu không có ngữ cảnh nhiều hơn.

Answer 3

Một mẹo hay là: API công khai lớp học của bạn (và bao gồm tên của nó) sẽ tiết lộ ý định, chứ không phải triển khai. Tôi (với tư cách là khách hàng) không quan tâm liệu bạn đã triển khai mẫu trình xây dựng hay mẫu nhà máy.

Không chỉ tên lớp có vẻ xấu, nó cũng không nói gì về những gì nó làm. Đó là tên dựa trên việc thực hiện và cấu trúc nội bộ của nó.

Tôi hiếm khi sử dụng tên mẫu trong một lớp, ngoại trừ (đôi khi) Nhà máy.

Edit:

Tìm thấy một thú vị article về đặt tên trên Coding Horror, xin vui lòng kiểm tra xem nó ra!

Answer 4

Tôi đã suy nghĩ tương tự. Trong trường hợp của tôi, sự phong phú của các nhà máy là do "xây dựng cho testability". Ví dụ: tôi có một hàm tạo như sau:

ParserBuilderFactoryImpl(ParserFactory psF) { 
... 
} 

Ở đây tôi có trình phân tích cú pháp - lớp tối ưu mà tôi cần. Trình phân tích cú pháp được xây dựng bằng cách gọi các phương thức trên trình tạo. Các nhà xây dựng (trình xây dựng mới cho mỗi trình phân tích cú pháp cần được xây dựng) được lấy từ nhà máy xây dựng.

Bây giờ, những gì h..l là ParserFactory? Ah, tôi rất vui vì bạn đã hỏi! Để kiểm tra việc thực hiện trình tạo phân tích cú pháp, tôi cần gọi phương thức của nó và sau đó xem loại phân tích cú pháp nào đã được tạo. Cách duy nhất để làm điều đó là phá vỡ sự incapsulation của lớp phân tích cú pháp cụ thể mà người xây dựng đang tạo ra là đặt một điểm đánh chặn ngay trước khi trình phân tích cú pháp được tạo ra, để xem cái gì đi vào hàm tạo của nó. Do đó ParserFactory. Nó chỉ là một cách để tôi quan sát trong một bài kiểm tra đơn vị những gì được truyền cho hàm tạo của một trình phân tích cú pháp.

Tôi không hoàn toàn chắc chắn cách giải quyết vấn đề này, nhưng tôi có cảm giác tốt hơn là nên đi vòng quanh lớp chứ không phải nhà máy, và Java sẽ làm tốt hơn nếu nó có phương pháp lớp thích hợp hơn là thành viên tĩnh.