Home Backend Development PHP Tutorial Object-oriented method 61 experience summaries of object-oriented analysis and design of PHP programs

Object-oriented method 61 experience summaries of object-oriented analysis and design of PHP programs

Jul 29, 2016 am 08:39 AM

(1) All data should be hidden inside the class where it is located.
(2) Users of a class must rely on the public interface of the class, but a class cannot rely on its users.
(3) Minimize the messages in the class protocol.
(4) Implement the most basic public interface that all classes understand [for example, copy operations (deep copy and shallow copy), equality judgment, correct output content, parsing from ASCII description, etc.].
(5) Do not put implementation details (such as private functions that place shared code) into the public interface of the class.
If two methods of a class have a common code, then you can create a private function that prevents this common code.
(6) Do not disturb the public interface of a class with things that users cannot use or are not interested in.
(7) There should be zero coupling between classes, or only exported coupling relationships. That is, one class either has nothing to do with another class, or it only uses operations in the public interface of another class.
(8) Classes should only represent one key abstraction.
All classes in the package should be jointly closed for changes in the same type of properties. If a change affects a package, it will affect all classes in the package, but will not have any impact on other packages.
(9) Centralize relevant data and behaviors.
Designers should pay attention to objects that obtain data from other objects through operations such as get. This type of behavior implies that this empirical principle is violated.
(10) Put irrelevant information in another class (that is, the behavior of not communicating with each other).
Move towards stable dependencies.
(11) Make sure the abstract concepts you model are classes, not just the roles played by objects.
(12) Distribute system functions as uniformly as possible in the horizontal direction, that is: according to design, top-level classes should share work uniformly.
(13) Do not create omnipotent classes/objects in your system. Be especially careful with classes whose names include Driver, Manager, System, and Susystem.
Plan an interface rather than implement an interface.
(14) Be careful with classes that define a large number of access methods in their public interfaces. The large number of access methods means that relevant data and behavior are not stored centrally.
(15) Be careful with classes that contain too many behaviors that don’t communicate with each other.
Another manifestation of this problem is creating a lot of get and set functions in the public interface of the class 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) Model according to the real world as much as possible (we often violate this principle in order to comply with the principle of system function distribution, avoid the all-purpose class principle, and centrally place relevant data and behaviors).
(18) Remove unnecessary classes from your design.
Generally speaking, we will downgrade this class to a property.
(19) Remove classes outside the system.
The characteristic of classes outside the system is that in abstract terms they only send messages to the system domain but do not accept messages from other classes in the system domain.
(20)Don’t turn operations into classes. Question any class whose name is a verb or derived from a verb, especially a class with only one meaningful action. Consider whether the meaningful behavior should be moved to a class that already exists or has not yet been discovered.
(21) We often introduce proxy classes when creating analysis models of applications. During the design phase, we often find that many agents are useless and should be removed.
(22) Minimize the number of collaborators of a class.
The number of other classes used by a class should be as small as possible.
(23) Minimize the number of messages passed between classes and collaborators.
(24) Minimize the amount of collaboration between classes and collaborators, that is: reduce the number of different messages passed between classes and collaborators.
(25) Minimize the fan-out of the class, that is: reduce the product of the number of messages defined by the class and the number of messages sent.
(26) If a class contains an object of another class, the containing class should send a message to the contained object. That is: an inclusion relation always implies a use relation.
(27) Most methods defined in a class should use most data members most of the time.
(28) The number of objects contained in a class should not exceed the capacity of the developer's short-term memory. This number is often 6.
When a class contains more than 6 data members, you can divide logically related data members into a group, and then use a new containing class to include this group of members.
(29) Let system functions be distributed vertically in a narrow and deep inheritance system.
(30) When implementing semantic constraints, it is best to implement them according to class definitions. This often leads to class overflow, in which case the constraints should be implemented in the behavior of the class, usually in the constructor, but not necessarily.
(31) When implementing semantic constraints in the constructor of a class, place the constraint test in the deepest inclusion level allowed by the constructor domain.
(32) If the semantic information that constraints rely on changes frequently, it is best to put it in a centralized 3rd party object.
(33) If the semantic information on which a constraint depends rarely changes, it is best distributed among the classes involved in the constraint.
(34) A class must know what it contains, but it cannot know who contains it.
(35) Objects that share literal scope (that is, are contained by the same class) should not have a usage relationship with each other.
(36) Inheritance should only be used to model specialization hierarchies.
(37) Derived classes must know the base class, and base classes should not know any information about their derived classes.
(38) All data in the base class should be private, do not use protected data.
Class designers should never put things in public interfaces that are not needed by users of the class.
(39) In theory, the inheritance hierarchy should be deeper, the deeper the better.
(40) In practice, the depth of the inheritance hierarchy should not exceed the short-term memory capacity of an average 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 commonalities in data, behavior, and/or interfaces as high-end as possible in the inheritance hierarchy.
(44) If two or more classes share common data (but no common behavior), then the common data should be placed in a class, and each class that shares this data contains this class.
(45) If two or more classes have common data and behavior (that is, methods), then each of these classes should inherit from a common base class that represents these data and methods.
(46) If two or more classes share a common interface (referring to messages, not methods), then they should inherit from a common base class only if they need to be used polymorphically.
(47) Case-by-case analysis of the display of object types is generally wrong. In most such cases, designers should use polymorphism.
(48) Case-by-case analysis of attribute value display is often wrong. Classes should be decoupled into an inheritance hierarchy, with each attribute value transformed into a derived class.
(49) Do not model the dynamic semantics of a class through inheritance relationships. Attempting to model dynamic semantics with static semantic relations results in switching types at runtime.
(50)Don’t turn class objects into derived classes. Be careful with any derived class that has only one instance.
(51) If you think you need to create a new class at runtime, take a step back and realize that you are creating objects. Now, generalize these objects into a class.
(52) It should be illegal to use empty methods (that is, methods that do nothing) in derived classes to override methods in base classes.
(53) Don’t confuse optional inclusion with the need for inheritance. Modeling optional inclusion as inheritance leads to a proliferation of classes.
(54) When creating inheritance hierarchies, try to create reusable frameworks rather than reusable components.
(55) If you use multiple inheritance in your design, assume you made a mistake. If you didn't make a mistake, you need to try to prove it.
(56) Whenever inheritance is used in object-oriented design, ask yourself two questions: (1) Is the derived class a special type of the thing it inherits? (2) Is the base class part of the derived class?
(57) If you find multiple inheritance in an object-oriented design, make sure that no base class is actually a derived class of another base class.
(58) In object-oriented design, if you need to choose between inclusion and association, please choose inclusion.
(59) Do not use global data or global functions for bookkeeping of objects of a class. Class variables or class methods should be used.
(60)Object-oriented designers should not let physical design principles undermine their logical designs. However, we often use physical design criteria in making decisions about logical design.
(61) Do not bypass the public interface to modify the state of the object.

The above has introduced the object-oriented method. A summary of 61 experiences in object-oriented analysis and design of PHP programs, including the object-oriented method. I hope it will be helpful to friends who are interested in PHP tutorials.

Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn

Hot AI Tools

Undresser.AI Undress

Undresser.AI Undress

AI-powered app for creating realistic nude photos

AI Clothes Remover

AI Clothes Remover

Online AI tool for removing clothes from photos.

Undress AI Tool

Undress AI Tool

Undress images for free

Clothoff.io

Clothoff.io

AI clothes remover

AI Hentai Generator

AI Hentai Generator

Generate AI Hentai for free.

Hot Article

R.E.P.O. Energy Crystals Explained and What They Do (Yellow Crystal)
2 weeks ago By 尊渡假赌尊渡假赌尊渡假赌
Repo: How To Revive Teammates
4 weeks ago By 尊渡假赌尊渡假赌尊渡假赌
Hello Kitty Island Adventure: How To Get Giant Seeds
3 weeks ago By 尊渡假赌尊渡假赌尊渡假赌

Hot Tools

Notepad++7.3.1

Notepad++7.3.1

Easy-to-use and free code editor

SublimeText3 Chinese version

SublimeText3 Chinese version

Chinese version, very easy to use

Zend Studio 13.0.1

Zend Studio 13.0.1

Powerful PHP integrated development environment

Dreamweaver CS6

Dreamweaver CS6

Visual web development tools

SublimeText3 Mac version

SublimeText3 Mac version

God-level code editing software (SublimeText3)

11 Best PHP URL Shortener Scripts (Free and Premium) 11 Best PHP URL Shortener Scripts (Free and Premium) Mar 03, 2025 am 10:49 AM

Long URLs, often cluttered with keywords and tracking parameters, can deter visitors. A URL shortening script offers a solution, creating concise links ideal for social media and other platforms. These scripts are valuable for individual websites a

Introduction to the Instagram API Introduction to the Instagram API Mar 02, 2025 am 09:32 AM

Following its high-profile acquisition by Facebook in 2012, Instagram adopted two sets of APIs for third-party use. These are the Instagram Graph API and the Instagram Basic Display API.As a developer building an app that requires information from a

Working with Flash Session Data in Laravel Working with Flash Session Data in Laravel Mar 12, 2025 pm 05:08 PM

Laravel simplifies handling temporary session data using its intuitive flash methods. This is perfect for displaying brief messages, alerts, or notifications within your application. Data persists only for the subsequent request by default: $request-

Build a React App With a Laravel Back End: Part 2, React Build a React App With a Laravel Back End: Part 2, React Mar 04, 2025 am 09:33 AM

This is the second and final part of the series on building a React application with a Laravel back-end. In the first part of the series, we created a RESTful API using Laravel for a basic product-listing application. In this tutorial, we will be dev

Simplified HTTP Response Mocking in Laravel Tests Simplified HTTP Response Mocking in Laravel Tests Mar 12, 2025 pm 05:09 PM

Laravel provides concise HTTP response simulation syntax, simplifying HTTP interaction testing. This approach significantly reduces code redundancy while making your test simulation more intuitive. The basic implementation provides a variety of response type shortcuts: use Illuminate\Support\Facades\Http; Http::fake([ 'google.com' => 'Hello World', 'github.com' => ['foo' => 'bar'], 'forge.laravel.com' =>

cURL in PHP: How to Use the PHP cURL Extension in REST APIs cURL in PHP: How to Use the PHP cURL Extension in REST APIs Mar 14, 2025 am 11:42 AM

The PHP Client URL (cURL) extension is a powerful tool for developers, enabling seamless interaction with remote servers and REST APIs. By leveraging libcurl, a well-respected multi-protocol file transfer library, PHP cURL facilitates efficient execution of various network protocols, including HTTP, HTTPS, and FTP. This extension offers granular control over HTTP requests, supports multiple concurrent operations, and provides built-in security features.

12 Best PHP Chat Scripts on CodeCanyon 12 Best PHP Chat Scripts on CodeCanyon Mar 13, 2025 pm 12:08 PM

Do you want to provide real-time, instant solutions to your customers' most pressing problems? Live chat lets you have real-time conversations with customers and resolve their problems instantly. It allows you to provide faster service to your custom

Announcement of 2025 PHP Situation Survey Announcement of 2025 PHP Situation Survey Mar 03, 2025 pm 04:20 PM

The 2025 PHP Landscape Survey investigates current PHP development trends. It explores framework usage, deployment methods, and challenges, aiming to provide insights for developers and businesses. The survey anticipates growth in modern PHP versio

See all articles