Graphical high cohesion and low coupling

Module

The module is to logically decompose the system into more subtle parts, divide and conquer, and solve complex problems in a number of simple problems, one by one.

The coupling mainly describes the relationship between the modules, and the cohesion mainly describes the internal module. The granularity of the module can be small, function, class, function block and so on.

Coupling

There are dependencies between modules, resulting in changes that may affect each other, the tighter the relationship, the stronger the coupling, and the worse the module independence.

For example, module a directly manipulate the data in Module B, is considered strong coupling, if a is only through the data and Module B interaction, it is considered weak coupling.

Independent modules are easy to expand, maintain, write unit tests, and if the modules are heavily dependent on each other, they can greatly reduce development efficiency.

Internal Poly

Elements inside the module, the stronger the correlation, the higher the cohesion, the module is more unitary. A module should perform a function as independently as possible,

If there are various scenarios that need to be introduced into the current module, the quality of the code becomes very fragile, which is recommended to split into multiple modules.

Low-cohesion module code, whether maintenance, expansion or refactoring are quite cumbersome, difficult to start.

Interface design Principles

Good interface should meet the design pattern six principles, many design patterns, the framework is based on high cohesion low coupling this starting point.

1. Single Responsibility Principle: a class is responsible for only one functional area of the corresponding responsibility.
2. Opening and closing principle: a software entity should be open for expansion and closed for modification.
3. The Richter substitution principle: All references to base classes (parent classes) must be able to transparently use objects of their subclasses.
4. Dependency reversal principle: abstractions should not be dependent on detail, and details should be dependent on abstraction. In other words, you want to program for the interface, not for the implementation.
5. Interface Isolation principle: use multiple specialized interfaces instead of a single total interface, that is, the client should not rely on interfaces that it does not need.
6. Dimitri rule: A software entity should interact with other entities as little as possible, such as appearance mode, exposing the unified interface externally.

Give me some chestnuts.

Appearance mode

It provides a consistent external call to multiple subsystems in the system, hides subsystem details from the client and reduces its coupling with subsystems.

Bridging mode

In JDBC, split isolation is made between the vendor-facing interface (Driver) and the consumer-facing API (DriverManager).

1         // developers only need to focus on the JDBC API, without having to focus on different database driver interface implementations 2         Class.forName ("Com.mysql.jdbc.Driver"); 3         Connection conn = drivermanager.getconnection (URL, username, password);

Adapter mode

Introduction of third-party libraries (Hibernate, log4j), should not be directly in the code to inherit or use the body class.

Need to pull out the upper unified interface, and then add the implementation class, exposing the interface externally.

1         // code strongly coupled with log4j, not recommended 2         Org.apache.log4j.Logger.getRootLogger (). info ("info"); 3         // The bottom layer is free to replace the log frame 4         Frloggerfactory.getlogger (). info ("info");