Why study design patterns? Can be in the project design research and development is well-founded, skilled, boast basis

All design patterns can not be separated from the object-oriented foundation, object-oriented is the root, the design principle is the trunk, the design pattern is the branch tender leaves;

object-oriented

Encapsulation, inheritance, polymorphism, abstraction, also known as object-oriented three features (encapsulation, inheritance, polymorphism)

It looks object oriented, but it’s actually process oriented

  1. Abusing getters and setters;
  2. Abuse of global variables, global methods;
    • The common constants class definition, it is better not to design a constant class separately, but to define which class uses a constant in that class;
    • Util, a class that contains only static methods, is thoroughly process-oriented;
  3. Define classes that separate data and methods, with data defined in one class and methods defined in another;

Interfaces, abstract classes

These two are object-oriented eternal topics, definition and distinction of their own Baidu bar, a bunch;

Abstract class is for code reuse, interface is for decoupling;

From the perspective of class inheritance level, abstract class is a bottom-up design idea. First, the code of the subclass is repeated, and then it is abstracted into the upper parent class. Interface, on the contrary, is a top-down design idea, first design interface, then consider the specific implementation;

Programming based on interfaces rather than implementations

  1. The naming of functions does not reveal task implementation details
  2. Encapsulate the implementation details
  3. Define an abstract interface for the implementation class

Use more composition and less inheritance

Inheritance has three main functions:

  1. Is – a relationship
  2. Support for polymorphic characteristics
  3. Code reuse

Composition, interfaces, and delegates can completely replace inheritance;

Anemia model (MVC), congestion model (DDD)

What is the anemia model?

Anaemic models, classes that contain only data, but no business logic, are poJOs, a typical process-oriented style;

Spring MVC architecture is a typical anaemic model MVC, emphasizing Service and light on BO (Business Object).

What is a hyperemic model?

Data and corresponding business logic are encapsulated in the same class, typical object-oriented style;

Domain-driven (DDD) is a typical congestion model, which is also divided into three layers, but the difference lies in the Service layer, which contains service class and Domain class. Compared with THE BO class, domain contains both data and business logic.

Why is anaemic MVC still prevalent? We all serve anaemic MVC models?

The business development of the system is relatively simple. The realization of simple CRUD operation congestion model is more difficult than that of anemia.

What scenarios should consider DDD development patterns?

Suitable for complex system development, specific see domain driven book