61 military rules for PHP object-oriented analysis and design-PHP Tutorial

61 military rules designed for PHP object-oriented analysis. You do not have to strictly abide by these principles and violate them and are not subject to religious penalties. However, you should regard these principles as warning bells. if you violate one of them, the warning bells will ring. You do not have to strictly abide by these principles and violate them and are not subject to religious penalties. However, you should regard these principles as warning bells. if you violate one of them, the warning bells will ring. ----- Arthur J. Riel

(1) all data should be hidden inside the class.

(2) a class user must depend on the common interfaces of the class, but the class cannot depend on its users.

(3) minimize messages in the protocol of the class.

(4) implement the most basic public interfaces that all classes understand [for example, copy operations (deep copy and shallow copy), equality judgment, correct output content, parsing from ASCII descriptions, etc.].

(5) Do not put implementation details (such as private functions with shared code) into the public interface of the class.

If two methods of the class have a piece of public code, you can create a private function to prevent the public code.

(6) Do not disturb the public interface of the class with something that the user cannot use or is not interested in.

(7) There should be zero coupling between classes, or only export coupling relationships. That is, a class is either unrelated to the other class, or only uses operations in the public interface of the other class.

(8) The class should only represent a key abstraction.

All classes in the package should be closed for changes to the same class nature. If a change affects a package, it will affect all classes in the package, without affecting other packages.

(9) place relevant data and behaviors in a centralized manner.

Designers should pay attention to the objects that obtain data from other objects through get and other operations. This type of behavior implies that this principle of experience has been violated.

(10) place irrelevant information in another class (that is, non-communication behavior ).

Dependency in a stable direction.

(11) make sure that the abstract concept you are modeling for is a class, not just the role played by an object.

(12) distribution of system functions in the horizontal direction as much as possible, that is, the top-level classes should share work in a unified manner according to the design.

(13) do not create all-powerful classes/objects in your system. Be especially careful about the classes whose names include Driver, Manager, System, and Susystem.

Plan an interface instead of implementing an interface.

• Four pages in total:
• Previous Page
• 1
• 2
• 3
• 4
• Next page

Bytes. But you should regard these principles as warning bells. if you violate one of them, the warning bells will ring ....