[TOC]

What are design patterns

** Definition: ** is a set of used, known, catalogued code design lessons

** Feature 1: ** Object-oriented

** Feature 2: ** is language independent

Why use design patterns?

  • extensible
  • reusable
  • Can be maintained
  • An abstract classImproved class and class cohesion, reduced code.
  • interface

When to use design patterns

  • Have some code writing experience and understanding
  • Suitable scenario + matching problem + clear solution – fixed business common + matching problem = scenario problem
  • refactoring: Improve the quality and performance of the software by adjusting the code structure, make the design pattern and architecture of the program more reasonable, and improve the scalability and maintainability of the software.

Four, six design principles

  • Single responsibility principle SRP
    • There is one and only one reason for a class to change
    • With duty or change and measure
  • Richter’s substitution principle
    • All references to a base class must be able to use its subclasses imperceptibly
    • A subclass extends, but does not modify, the functionality of its parent class
  • Dependency inversion principle
    • Interface oriented programming
  • Interface Isolation Principle
    • Interfaces should be as detailed as possible and reduced to minimum functional units
    • Don’t rely on not using interfaces
  • Demeter’s rule
    • Also known as the least know principle, one object knows the least about the other
    • Only talk to your Immediate friends
    • Dependency, association, aggregation, composition
  • The open closed principle
    • Open for extensions, closed for modifications
    • Abstract constraints and encapsulate change

Five, do not follow the design pattern may lead to problems

Technical liabilities:

Case 1:

Xiao Ming needed to develop a user module, which involved some complex operations, such as user data reception and processing. At this time, in order to save trouble, Xiao Ming integrated the codes that needed to interact between multiple modules, and completed the work in one day, which originally needed two days. But after a period of time, the project to upgrade the iteration, involving the receiving part of the user data, there is a big change, at this time because the code does not follow any specification, is a mess, the need for the modification of large area, and even delete rewritten, effort to turn over more than times right now, xiao Ming dug a huge pit for oneself, need to work overtime to fill in the pit!

Example 2:

When xiao Ming wrote the program, he handled a service node of 5000QPS very poorly, resulting in that one node could only have 1000QPS. At this time, it was necessary to use 5 machines to solve the problem of 5000QPS, which resulted in an increase in cost

What is high cohesion, low coupling and strong coupling

High cohesion: module A with all the functions it should have, no dependency on other modules, disassembled to the point of no further disassembly (minimal service of microservices, minimal atomic operations)

Low coupling: low dependency between modules, when a module changes or fails

For example: A module depends on B module, B interface depends on, B problems, A is not affected, this is low coupling

But if, at the same time, A is affected and can’t function properly, that’s strong coupling

Design patterns and principles in business logic

  • Single responsibility principle

    Business Layer (horizontal + vertical) Spring MVC, Controller, Service, Dao

  • Dependency lead principle

    Services, DAOs, etc., all have interfaces and Impl implementation classes

  • Demeter’s rule

    Horizontal layers, such as Controller and Service

  • Multiple modes are used in combination

    Dao layer: Facade mode, Proxy mode, Strategy mode

    Service layer: Business customization

Common design patterns in frameworks

Common design patterns in Spring

  • Factory Pattern Indicates the Factory Pattern

    • BeanFactory
    • ApplicationContext

  • Singleton Singleton pattern

    • ApplicationContext

  • Prototype

    • scope = prototype

  • Proxy Pattern Indicates the Proxy Pattern

    • AOP

  • Delegate Proxy Indicates the delegation mode

    • DispatchServlet
    • BeanDefinitionParserDelegate

  • Observer Pattern

    • ContextLoaderListener

  • Adapter Adapter mode

    • HandlerAdapter

  • Other Pattern Other design patterns

    • Policy pattern, template method pattern

Common design patterns in Mybatis

  • The factory pattern
    • SqlSessionFactory
  • The singleton pattern
    • SqlSessionFactory
  • The proxy pattern
    • MapperProxy, ConnectionLogger, and others use dynamic proxies
  • Template method pattern
    • BaseExecutor, SimpleExecutor, BaseTypeHandler
  • Decorator pattern
    • All decorators implementation classes under decorators in the cache package
  • Iterator pattern
    • PropertyTokenizer

Common design patterns in architecture

  • The MVC pattern
  • The blackboard model
  • A master-slave mode
  • SOA patterns
  • Microservice model

Summary of design pattern

Experience the reuse extensible In the logic
Can be created reusable Tools and frameworks
To solve the problem Can I IE hu In the architecture

You must be able to draw UML diagrams. If you are asked about design patterns in an interview, drawing UML is a necessary process

The difference and connection between implementation and inheritance

First, we all know that Java is single-inheritance, multi-implementation

**extends: ** IF a class extends from a parent class, it has all the non-private functions of the parent class. It is implementable. All subclasses inherit methods from the parent class using the same behavior

**Implement: ** interface, relatively abstract, is only defined, with functions handed over to the implementation class to Implement different behavior according to need

The relationships and differences between SOA and microservices

Here is my understanding of SOA and microservices, as there is no actual operation, if you have any questions, please give me more advice!

**SOA: ** mainly aims at solving the problem of mutual invocation between multiple services, that is, service governance. Modules are extracted according to functions to provide a common service for multiple modules to call, focusing on central management.

** Microservices: ** Each service is focused on a single small business function, private database, data decentralization, reduce the degree of direct coupling of services, each service can be deployed independently, it is highly cohesive, loose coupling focuses on decentralized management