Làm thế nào để tôi tránh viết các lớp Manager?

Tôi dường như tiếp tục đọc nó là một ý tưởng tồi khi sử dụng XxxManagercác lớp phong cách trong lập trình công cụ trò chơi, nhưng ngay cả khi tôi cố gắng tránh sử dụng chúng, tôi luôn kết thúc với thứ gì đó chứa tất cả các vị trí diễn viên / thực thể / thế giới trò chơi và hành động theo họ, kết thúc là một Managernếu bởi một tên khác.

Đây thực sự là một mô hình xấu để làm theo? Nếu vậy, các lựa chọn thay thế là gì?

Các lớp "Manager" có thể có vấn đề vì nhiều lý do. Hai lý do chính có xu hướng là:

• tên không rõ ràng (những gì thực sự "quản lý" đòi hỏi, và nó luôn luôn giống nhau cho mọi loại điều được quản lý?)
• họ có xu hướng hướng tới các nhóm chức năng vi phạm nguyên tắc trách nhiệm duy nhất (nghĩa là một loại nên làm một việc)

Thường thì một trong những lý do đó gây ra hoặc ngụ ý khác.

Những vấn đề đó là những điều tốt để ghi nhớ, nhưng đừng để chúng làm tê liệt khả năng thực sự tạo ra trò chơi của bạn . Cuối cùng, không ai quan tâm đến những gì các lớp học của bạn được gọi hoặc những gì họ làm. Họ sẽ quan tâm đến trò chơi của bạn.

Thông thường khá dễ dàng để tách hầu hết các "nhà quản lý" thành hai phần:

• phần lưu trữ các đối tượng thực tế và cung cấp quyền truy cập vào chúng (mà bạn có thể gọi là "kho", "kho", "cơ sở dữ liệu", "bộ đệm" hoặc nhiều thứ khác. Đây là loại thường chịu trách nhiệm trong suốt vòng đời của các đối tượng, nghĩa là khi một đối tượng bị xóa khỏi hoặc không còn được chứa bởi một thể hiện của loại này thì nó không còn tồn tại.

• phần xử lý các đối tượng thực tế và thực hiện một số công việc trên chúng. Nó có thể cập nhật các đối tượng đó (sau đó là "trình cập nhật" hoặc "mô phỏng") hoặc nó có thể vẽ chúng (sau đó là "ngăn kéo" hoặc "trình kết xuất"). Hoặc nó có thể làm một cái gì đó khác với họ; điều quan trọng là đặt tên theo mục đích chính của nó. Bạn thường đưa ra các thể hiện của loại này một thể hiện hoặc tham chiếu đến các thể hiện của loại đầu tiên (loại chỉ xử lý vòng đời của các đối tượng).

Một lập luận hợp lý có thể được đưa ra là tên của loại đầu tiên có thể bao gồm trình quản lý (vì nó "quản lý vòng đời của" một số đối tượng). Thế giới sẽ không kết thúc nếu bạn đặt tên cho loại của mình như vậy, mặc dù bạn có thể cần phải đưa ra các phản ứng giật đầu gối ở dạng "không gọi người quản lý" thường xuyên hơn, vì vậy bạn có thể muốn tránh điều đó chỉ vì điều đó.

Khi bạn đọc bài đăng trên blog mà bạn đã liên kết đến trong các bình luận, thì bạn sẽ thấy rằng "trở thành Người quản lý nếu bằng tên khác" chính xác là những gì nó muốn bạn làm. Đó là sự đồng thuận chung trong phát triển phần mềm rằng các biến toàn cầu là xấu và thay thế duy nhất là mọi dữ liệu đều được giữ bởi dữ liệu khác.

Vấn đề với một lớp có tên FoobarManagerlà từ "Manager" không cho bạn biết lớp thực sự làm gì. Ví dụ:

• Khi nó điều khiển cơ chế trò chơi của foobars, bạn có thể đặt tên cho nó FoobarController.
• Khi nó khởi tạo foobars nhưng sau đó ủy quyền điều khiển cho thứ khác, đó là một FoobarFactoryhoặc FoobarBuilder.
• Khi nó vẽ foobars lên màn hình, đó là một FoobarRenderer.
• Khi nó lắng nghe các sự kiện được tạo bởi foobars, đó là một FoobarEventHandler.
• Khi nó chờ đợi điều gì đó xảy ra với các foobars, đó là một FoobarObserver.
• Khi nó chỉ là một người giữ dữ liệu câm cho một bộ sưu tập các foobars mà không có logic nào cả, bạn chỉ cần đặt tên cho nó Foobars.

Bạn có thể đặt tên bất kỳ của các lớp này là "Manager". Nhưng sau đó nó có thể thực hiện bất kỳ chức năng nào trong số này. Và sau này khi bạn nhận ra rằng bạn cần một chức năng khác ở trên, bạn cũng sẽ tích hợp nó vào FoobarManager. Vì vậy, bạn sẽ kết thúc với một Đối tượng Thần phá vỡ nguyên tắc Tách biệt các mối quan tâm (mỗi lớp nên làm chính xác một điều).