Lời khuyên / lời khuyên về cách giảm việc sử dụng các lớp học của người quản lý thành công?

Đôi khi tôi nghe nói rằng có quá nhiều lớp "người quản lý" trong thiết kế chương trình của bạn là mùi mã và thêm một lớp phức tạp không cần thiết. Đối với tôi, điều hợp lý là mọi người muốn sử dụng các lớp trình quản lý để thao tác và kiểm soát các đối tượng từ một bối cảnh có ý nghĩa với họ, nhưng tìm ra cách làm cho một giải pháp hoạt động mà không có chúng có thể gây nhầm lẫn.

Có nên thực sự tránh các lớp người quản lý càng nhiều càng tốt? Ngoài ra, những bài báo / giấy tờ nào tôi nên đọc về cách triển khai một công việc thay thế xung quanh cho các trường hợp chung / chung mà những người quản lý này có thể được gỡ bỏ?

Có thể có hai lý do đây là mùi mã. Một lý do là, điều đó có thể có nghĩa là bạn không có các đối tượng miền mà thay vào đó bạn có các đối tượng giá trị chỉ lưu trữ dữ liệu để thao tác bởi các lớp trình điều khiển hoặc trình quản lý. Điều này thực sự khá phổ biến và tương đương với lập trình thủ tục bằng ngôn ngữ OO. "Rất nhiều người quản lý" có thể là một gợi ý rằng bạn cần tích hợp logic trạng thái, xác thực và các mối quan tâm trực tiếp khác vào các đối tượng miền để chúng thực sự gói gọn một cái gì đó. Tất nhiên có những gợi ý lớn hơn như thực tế là bạn không có phương pháp nào khác ngoài getter / setters.

Một lý do khác khiến nó có mùi mã là nó có thể có nghĩa là các đối tượng miền của bạn không thực sự liên quan với nhau. Chẳng hạn, nếu bạn có một lớp Tài khoản thực sự không biết gì về lớp Giao dịch ngoại trừ nó có tên là Giao dịch và có thể có nhiều hơn một trong số chúng, thì bạn lại không thực sự có triển khai miền doanh nghiệp rất sôi động. Ví dụ: SavingsAccount có thể biết rằng nó không thể chấp nhận Giao dịch ghi nợ nếu tài khoảnStatus bị đóng. Rất nhiều triển khai sẽ để lại cho người quản lý.

Có nhiều lớp "trình quản lý" thường là một biểu tượng của mô hình miền thiếu máu , trong đó logic miền được đưa ra khỏi mô hình miền và thay vào đó được đặt trong các lớp của trình quản lý, ít nhiều tương đương với các tập lệnh giao dịch . Điều nguy hiểm ở đây là về cơ bản bạn đang quay trở lại lập trình thủ tục - rằng bản thân nó có thể hoặc không phải là một điều tốt tùy thuộc vào dự án của bạn - nhưng thực tế là nó không được xem xét hoặc dự định là imo "mùi mã".

Theo nguyên tắc của "chuyên gia thông tin" , một hoạt động logic sẽ nằm càng gần với dữ liệu mà nó yêu cầu càng tốt. Điều này có nghĩa là chuyển logic miền trở lại mô hình miền, do đó, các hoạt động logic này có ảnh hưởng rõ rệt đến trạng thái của mô hình miền, thay vì các tập lệnh giao dịch thay đổi trạng thái của mô hình miền từ bên ngoài.

Vấn đề lớn nhất với Lớp quản lý là chúng chỉ đại diện cho ý tưởng mơ hồ này về những gì lớp phải làm. Nếu bạn gọi một cái gì đó là Manager thì nó có thể làm bất cứ điều gì và mọi thứ có thể liên quan đến bất cứ thứ gì nó đang quản lý. Tôi cho rằng trong một số bối cảnh có thể ổn, nhưng tôi sẽ nói trong hầu hết các trường hợp không phải là điều bạn muốn. Bạn muốn ai đó có thể nhìn vào tên lớp và không chỉ có ý tưởng tốt về những gì lớp học làm mà còn cả những gì nó không làm.

Một vấn đề khác với các lớp trình quản lý là nó làm cho rất khó để quyết định chức năng nên đi đâu. Khi có rất nhiều lớp người quản lý thì thường có rất nhiều sự chồng chéo về chức năng giữa các lớp người quản lý. Sau đó, bạn phải tìm ra lớp nào sẽ thực hiện chức năng chồng chéo đó và tất nhiên người khác sẽ chọn khác. Vì vậy, khi họ tìm kiếm chức năng và không thấy nó ở nơi họ mong đợi thì họ sẽ tiếp tục và triển khai lại nó ở nơi họ nghĩ rằng nó thuộc về vì họ không biết đến sự tồn tại của việc triển khai khác. Nói cách khác, các lớp quản lý dẫn đến các thiết kế khó hiểu và thường xuyên bị gây rối.