Design patterns and object-oriented design principles

1: Policy mode

The policy pattern defines the algorithm families, which are encapsulated separately so that they can be replaced with each other, and this pattern makes the algorithm independent of the customer using the algorithm.

Package changes, multi-use combinations less inheritance, programming for interfaces rather than for implementation.

2: Observer mode

The Observer pattern defines a one-to-many dependency of an object, so that when an object state changes, all objects that depend on it are notified and updated automatically.

Designed for loose coupling between objects.

3: Template Method mode

The template method pattern defines the skeleton of the algorithm in one method, and some steps defer to the solid line in the subclass, and the template method allows the subclass to redefine some steps of the algorithm without altering the algorithm structure.

The high-level component calls the underlying component, relies on the inversion principle, uses the concrete class without change, uses abstraction, facilitates decoupling.

4: Decorator Mode

The decorator mode dynamically attaches responsibility to the object, and if you want to expand the feature decorator provides a more resilient alternative than inheritance.

Decorators and decorated objects have the same superclass.

You can decorate an object with one or more decorators

Since decorators and decorators are made of the same superclass, they can be replaced with objects that have been decorated in any situation where the original object is needed.

The decorator may, before or after the act entrusted to the decorator, add his or her actions to achieve a specific purpose.

Objects can be decorated at any time, so you can use your favorite decorator to decorate objects dynamically and without limits at run time.

The class should be open for expansion and closed for modification.

5: Factory Method mode

Factory method Mode: Defines an interface to create an object, but subclasses decide which class to instantiate. The factory method defers the instantiation of the class to the subclass.

Dependency inversion principle: to rely on abstraction, do not rely on a specific class.

Do not overwrite methods already implemented in the base class

Do not let classes derive from specific classes

A variable cannot hold a reference to a specific class

6: Abstract Factory Method mode provides an interface for creating a family of related or dependent objects without having to specify a specific class.

The factory method pattern uses inheritance: Delegate the creation of objects to subclasses, subclasses implement factory methods to create objects, and abstract factory method patterns use a combination: object creation is implemented in the method exposed by the factory interface.

Object-Oriented design principles:

Single responsibility Principle: For a class, there should be only one cause for it to change.

If a class takes on too much responsibility, it is tantamount to coupling his duties, and a change in one's responsibilities may weaken or deter the ability of the class to carry out other duties.

Cohesion: The functional correlation between the constituent principles of a module.

Open closure principle: Software entities (classes, modules, functions) should be scalable, but cannot be modified.

The key is abstraction. The module can manipulate an abstract body, in which the module relies on a fixed abstract body, so it can be closed for modification, and through this abstract derivation, it can also extend the behavior of this module.

Developers should abstract only those parts of the program that exhibit frequent changes, rejecting immature abstractions and abstractions as important as themselves.

The Richter replacement principle:

Its subclass object can be substituted for the parent class object, but its parent object cannot be substituted for the subclass object. In a software system, subclasses should be able to replace any base class where it can appear, and the code will work properly after being replaced.

Dependency Inversion principle:

High-level modules should not rely on the underlying modules both should be dependent on the abstract

Abstractions should not depend on specific details, and details should be dependent on abstraction

All well-designed object-oriented architectures should have a clear architecture, each with a well-defined, controlled interface that provides a cohesive service to the outside.

Any variable should not hold a pointer to a specific class or a reference

No method should derive from a specific class

No method should be overridden in any of his base classes for a method that already has a solid line

Design patterns and object-oriented design principles