This is the 10th day of my participation in the August More Text Challenge. For details, see:August is more challenging

Design Patterns 🎈

Design patterns: a set of repeated, widely known, catalogued, and widely used summaries of code design experiences. Design patterns are used to reuse code, make it easier for others to understand, ensure code reliability, and reuse of programs. Design patterns make code development truly engineering; Design patterns are as fundamental to software engineering as they are to the structure of a building. Only by ramming the foundation and building the structure can we build a strong building. It’s also a step towards becoming a senior developer. Conclusion: == Design pattern is the summary of design experience ==

🙈 Created:

  1. Singleton patterns guarantee that a class has only one instance and provide a global point of access to it
  2. Abstract Factories are used to provide an interface for creating a set of related or interdependent objects without specifying their concrete classes.
  3. The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to create different representations.
  4. The Factory Method pattern defines an interface for creating an object, and lets subclasses decide which class to instantiate. The Factory Method delays the instantiation of a class to its subclasses.
  5. The Prototype pattern uses the Prototype instance to specify the type of object to be created, and copies the Prototype to create new objects.

🙊 Structural:

  1. Adapter patterns are well understood literally. Transform the interface of each class into another interface that the customer wants. Adapter allows classes that are not compatible with their interfaces to work together.
  2. Bridge patterns separate the abstract part from its implementation part, allowing both to vary independently.
  3. Decorator patterns dynamically add additional responsibility to an object. In terms of extensibility, the Decorator pattern is more flexible than the subclassing approach.
  4. Composite patterns combine objects into tree structures to represent a partial-whole hierarchy. Composite enables customers to use single objects and Composite objects consistently.
  5. A Facade Pattern provides a consistent interface to a set of interfaces in a system. The Facade Pattern defines a high-level interface that makes the subsystem easier to use.
  6. Flyweight patterns use sharing techniques to effectively support a large number of fine-grained objects.
  7. Proxy patterns provide a Proxy for other objects to control access to this object.

🙉 Behavioral type:

  1. Template methods define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method allows subclasses to redefine specific steps of an algorithm without changing the algorithm’s structure.
  2. Command patterns encapsulate a request into an object, allowing you to parameterize customers with different requests. Queue or log requests, and support cancelable operations.
  3. The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing the object’s internal representation.
  4. An Observer Pattern defines a one-to-many dependency between objects so that when an object’s state changes, all dependent objects are notified and automatically refreshed.
  5. Given a language, define a representation of its grammar, and define an Interpreter that uses that representation to interpret sentences in the language. What the interpreter pattern needs to address is that if a particular type of problem occurs frequently enough, it may be worth expressing instances of that problem as sentences in a simple language. This allows you to build an interpreter that solves the problem by interpreting these sentences. For example, regular expressions.
  6. The Mediator Pattern uses a mediation object to encapsulate a series of object interactions. Intermediaries keep objects loosely coupled by eliminating the need to refer to each other explicitly, and can change their interactions independently.
  7. In the Chain of Responsibility Pattern, multiple objects have the opportunity to process the request in order to decouple the sender and receiver of the request. Chain the objects and pass the request along the chain until an object processes it.
  8. The Memento Pattern captures the internal state of an object and holds that state outside of the object without breaking encapsulation. You can then restore the object to its saved state.
  9. A Strategy Pattern defines a set of algorithms, encapsulates them one by one, and makes them interchangeable. This pattern allows the algorithm to change independently of the customers who use it.
  10. A Visitor Pattern represents an operation that acts on elements in an object structure. It allows you to define new operations on elements without changing their classes.
  11. State patterns allow an object to change its behavior when its internal State changes. The object appears to modify the class to which it belongs.

Six design principles 🎉

(1) Single Responsibility Principle

Definition: a class is responsible for only one function area, or it can be defined as: for a class, there should be only one reason for it to change.

(2) Liskov Substitution Principle

Definition: using the abstract and polymorphic | all references to base classes (parent) must be able to transparently use objects of derived classes without knowing it. 1) If for every object o1 of type S, there is an object O2 of type T, such that the behavior of all programs P defined in terms of T does not change when all objects O1 are replaced with O2, then S is a subtype of T. 2) As long as the superclass can appear where the subclass can appear, and the replacement of the subclass will not produce any error or exception, the user may not need to know whether the superclass or the subclass. Conversely, where there are subclasses, the superclass does not necessarily fit

(3) Dependence Inversion Principle (DIP)

Definition: high-level modules should not depend on low-level modules, both should depend on their abstractions; Abstractions should not depend on details, and details should depend on abstractions. The core idea is to program to interfaces, not implementations.

(4) Interface Segregation Principle (ISP)

Definition: Use multiple specialized interfaces rather than a single overall interface, i.e. a client should not rely on interfaces it does not need.

(5) Law of Demeter (LOD)

Definition: Minimize class to class connections A software entity should interact with as few other entities as possible.

(6) Open-closed Principle (OCP)

Definition: Open for extension, closed for modification A software entity should be open for extension, but closed for modification. That is, software entities should be expanded as much as possible without modifying the original code