Summary of principles for PHP program development

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 URJ. 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 interface that all classes understand. [for example, copying a copy does not have to strictly abide by these principles, and violating them will not be 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.

(14) be careful with classes that define a large number of access methods in public interfaces. A large number of access methods mean that related data and behaviors are not stored in a centralized manner.

(15) be careful with classes that contain too many non-communication behaviors.

Another manifestation of this problem is that many get and set functions are created in the public interfaces of classes in your application.

(16) in an application composed of an object-oriented model that interacts with the user interface, the model should not depend on the interface, but the interface should depend on the model.

(17) modeling in the real world as much as possible (we often violate this principle in order to comply with the principles of system function distribution, to avoid all-encompassing principles, and to centralize the placement of relevant data and behavior ).

(18) remove unnecessary classes from your design.

In general, we will downgrade this class to an attribute.

(19) remove classes outside the system.

Classes outside the system are abstracted to send messages only to the system domain, but do not accept messages sent from other classes in the system domain.

(20) do not change operations into classes. Question any class whose name is a verb or a derived automatic word, especially a class with only one meaningful action. Consider whether the meaningful behavior should be migrated to an existing or undiscovered class.

(21) we often introduce a proxy class when creating an analysis model for an application. In the design phase, we often find that many agents are useless and should be removed.

(22) minimize the number of collaborators of classes.

The number of other classes used by a class should be as small as possible.

(23) minimize the number of messages transmitted between classes and collaborators.

(24) minimize the amount of collaboration between classes and collaborators, that is, reduce the number of different messages transmitted between classes and collaborators.

(25) minimize fan-out of a class, that is, reduce the product of the number of messages defined by the class and the number of messages sent.

(26) if the class contains an object of another class, the containing class should send a message to the contained object. That is, the inclusion relationship always means that the link is used.

(27) most methods defined in a class should use most data members most of the time.

(28) the number of objects contained in the class should not exceed the developer's short-term memory capacity. This number is usually 6.

When a class contains more than 6 data members, you can divide logical data members into a group, and then use a new include class to include the group members.

12 Next page