Lập Trình Máy Tính Đối Tượng Thượng Đế

Đối tượng thượng đế là một ví dụ về phản mô thức (en) (anti-pattern).

Một kỹ thuật lập trình phổ biến là tách (en) một vấn đề lớn thành nhiều vấn đề nhỏ hơn (chiến lược chia để trị) và tạo ra giải pháp cho từng vấn đề. Một khi các vấn đề nhỏ hơn được giải quyết, thì vấn đề lớn nói chung cũng đã được giải quyết. Do đó, một đối tượng nhất định cho một vấn đề nhỏ thì chỉ cần biết về chính nó thôi. Tương tự như vậy, chỉ có 1 tập hợp các vấn đề mà một đối tượng cần giải quyết: các vấn đề của chính nó.

Ngược lại, một chương trình sử dụng một Đối tượng thượng đế thì lại không theo hướng tiếp cận này. Hầu hết các chức năng tổng thể của chương trình như vậy thì đều được code thành một đối tượng "biết tuốt" đơn nhất, bảo quản hầu hết thông tin về toàn bộ chương trình và cũng cung cấp hầu hết các phương thức để thao tác với các dữ liệu này. Bởi vì đối tượng này chứa rất nhiều dữ liệu và đòi hỏi rất nhiều phương thức, nên vai trò của nó trong chương trình trở nên giống như Thượng đế (biết tất cả và bao quát tất cả). Thay vì việc 'các đối tượng chương trình' giao tiếp trực tiếp với nhau, thì 'các đối tượng khác trong chương trình' dựa dẫm vào Đối tượng thượng đế đơn nhất đấy cho hầu hết thông tin và tương tác của chúng. Vì đối tượng này được ngẫu hợp chặt chẽ (en) (được tham chiếu) với rất là nhiều mã khác, nên việc bảo trì trở nên khó khăn hơn so với hệ quả khi thiết kế dàn trải đều ra các đối tượng lẻ. 'Những thay đổi được thực hiện cho đối tượng đấy vì lợi ích cho một thường quy' thì có thể có tác dụng ngoài ý muốn lên các thường quy không liên quan khác.

Một Đối tượng thượng đế là 'thứ tương tự trong lập trình hướng đối tượng' cho việc không dùng chương trình con trong các ngôn ngữ lập trình thủ tục, hoặc sử dụng quá nhiều biến toàn cục để lưu trữ thông tin trạng thái.

Tuy rằng việc tạo một Đối tượng thượng đế thì thường được coi là sự thực hành lập trình không tốt, kỹ thuật này đôi khi được sử dụng cho các môi trường lập trình chặt chẽ (như vi điều khiển), tại đó việc tăng hiệu suất và sự tập trung kiểm soát thì quan trọng hơn tính khả bảo trì và sự tao nhã lập trình.

• Mã Ravioli – mô thức đối nghịch với cái này

• Riel, Arthur J. (1996). “Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications”. Object-Oriented Design Heuristics. Boston, Massachusetts: Addison-Wesley. ISBN 0-201-63385-X. 3.2: Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem.
• Anti-Patterns and Worst Practices – Monster Objects.