Php object-oriented programming principles

Welcome to the Linux community forum and interact with 2 million technical staff to access 61 principles of php object-oriented programming language (OOP). If you have mastered the following principles, you must be a strong php developer. (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)

Welcome to the Linux community forum and interact with 2 million technical staff> go to the 61 principles of php Object-Oriented Programming (OOP). If you have mastered the following principles, you must be a strong php expert. (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)

Welcome to the Linux community forum and interact with 2 million technicians>

Php Object-Oriented Programming (OOP) 61 principles, master the following principles you must be a strong php.

(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.

(29) vertical distribution of system functions in a narrow and deep inheritance system.

(30) when implementing semantic constraints, it is best to implement them according to the class definition. This often causes class flooding. In this case, constraints should be implemented in class behavior, usually in constructors, but not necessarily.

(31) when implementing semantic constraints in class constructor, place the constraint test in the include level as deep as possible allowed in the constructor field.

(32) if the semantic information on which the constraint depends changes frequently, it is best to put it in a centralized 3rd-party object.

(33) if the semantic information on which the constraint depends is rarely changed, it is best to distribute it among the classes involved in the constraint.

(34) The class must know what it contains, but cannot know who contains it.

(35) objects in the shared literal scope (that is, objects contained by the same class) should not be used with each other.

(36) inheritance should only be used to model the special hierarchies.

(37) The derived class must know the base class, and the base class should not know any information about their derived classes.

(38) All data in the base class should be private. Do not use data protection.

Class designers should never put things that class users don't need in public interfaces.

(39) theoretically, the hierarchy of inheritance should be deeper, the deeper the better.

(40) In practice, the depth of the hierarchy should not exceed the short-term memory capacity of an ordinary person. A widely accepted depth value is 6.

(41) All abstract classes should be base classes.

(42) All base classes should be abstract classes.

(43) put data, behavior, and/or interface commonalities as high as possible in the inheritance hierarchy.

[1] [2]