Everything is an object.

Everything is an object.

If a language is a superset of another language, the language will be backward compatible and will become bloated. In some aspects, the language is too complex, such as c ++

2. References can exist independently. When initializing a reference, it adds an association such as string a; and string a = "as" to this reference"

3. constants are usually used inside the program, but can also be stored in non-rom memory (read-only memory ).

4. the simpler the things, the more plasticity they are, the more modifications they can be made on this basis. For complex things, the opposite is true. The price to change is very high, and the effect is not as high as expected. Closeness is suitable for complex and simple abstraction. The superstructure depends on the underlying layer, but it requires different responses as time goes by, with more and more responsibilities. The functions of upper-layer buildings depend on the bottom layer. To assign different responsibilities to them, the bottom layer should be changed to meet the new minimum unit (only one responsibility is assigned. Therefore, the abstraction layer is reflected between the upper layer and the base layer, so that the upper layer depends on an abstraction layer. In the abstraction layer, you can choose to add new minimum units and high-level dependency abstraction.

6. Five Principles:

Single Responsibility Principle SRP: Single Responsibility Principle

OCP: Open-Close Principle

Liskov replacement Principle LSP: Liskov Substitution Principle

Dependency inversion Principle DIP: Dependency Invertion Principle

Interface isolation Principle ISP: Interface Separate Principle

 

In object-oriented design, how to deal with changes in design requirements through small changes is a matter of great concern to designers. To this end, many OO pioneers have proposed many object-oriented design principles to guide the design and development of OO. Below are several design principles related to class design.

 

1. the Open Closed Principle OCP)

A module should be open in terms of scalability and closed in terms of modification. Therefore, the interface encapsulation mechanism, abstract mechanism, and polymorphism technology should be considered in object-oriented design. This principle is also suitable for non-object-oriented design, and is one of the important principles of software engineering design methods. Let's take the radio as an example to describe the object-oriented open and closed principle. When we listen to the program, we need to turn on the radio power to align the radio frequency and adjust the volume. However, for different radios, the details of the three steps are often different. For example, the Operation Details of auto-shrinking radio stations are not the same as those of the pay-as-you-go radio station. Therefore, we are unlikely to implement (reload) these different operations for different types of radios through a radio class. However, we can define a radio interface that provides six Abstract METHODS: boot, shutdown, increase frequency, decrease frequency, increase volume, and decrease volume. Different radios inherit and implement these six abstract methods. In this way, the new radio type will not affect other original radio types, and it is very convenient to expand the radio type. In addition, the existing radio type does not affect other types of radios when you modify the operation method.

 

2. replacement Principle (the Liskov Substitution Principle LSP)

Subclass should be able to replace the parent class and appear anywhere the parent class can appear. This principle is the design principle proposed by Liskov in 1987. It can also be introduced from the Design by Contract concept of Bertrand Meyer.

Take the students as an example. The night students are child classes of the students, so they can appear anywhere they can. This example is somewhat far-fetched. In an example that can reflect this principle, the circle is a special subclass of the elliptical. Therefore, the circle can appear in any place where an ellipse occurs. But in turn, it may not work.

When using the replacement principle, we try to design class B as an abstract class or interface so that class C inherits Class B (interface B) and implements operations A and B, class C instance replaces B, so that we can extend the new class (inheriting Class B or interface B) without modifying Class.

 

3. the Dependency Inversion Principle DIP)

During business design, dependencies related to specific businesses should be dependent on interfaces and abstract classes as much as possible, rather than specific classes. A specific category is only responsible for the implementation of the relevant business. modifying a specific category does not affect the dependencies related to the specific business.

In the structural design, we can see that the underlying module implements the high-level abstraction module (the high-level abstraction module calls the underlying module, abstract modules depend on specific implementation modules. Changes to the specific implementation of the underlying modules will seriously affect the high-level abstract modules. This is obviously a "hard nut to crack" of the structured method ".

The dependency between object-oriented methods is the opposite. The specific implementation classes depend on abstract classes and interfaces.

Therefore, during business design, we should try to define the prototype of the Business Method in the interface or abstract class, and implement the business method through the specific implementation class (subclass, the modification of the Business Method content does not affect the calling of the business method at runtime.

 

4. the Interface Segregation Principle ISP)

Using multiple interfaces related to a specific customer class is better than using a common interface that covers multiple business methods.

The ISP principle is another enabling technology that supports components such as COM. Without ISP, the availability and portability of components and classes will be greatly reduced.

The essence of this principle is quite simple. If you have a class for multiple customers, creating a specific business interface for each customer, then it is more effective to make the customer class inherit multiple specific business interfaces than to directly load all the methods required by the customer.

 

The above four principles are commonly used in object orientation. In addition to the above four principles, there are also some common experiences, such as the class structure level should be three to four layers, and the class responsibilities should be clarified (one class corresponds to one specific duty) for our reference in object-oriented design. However, from the above several principles, we can see that these classes present the relationship of tree topology in geometric distribution, which is a good and open linear relationship with low design complexity. In general, in software design, we should try to avoid designing relationships with closures and loops. They reflect a large degree of coupling and design complexity.