Shulou(Shulou.com)06/02 Report--

This article mainly explains "the introduction of single responsibility principle and interface isolation principle in the seven design principles of java design pattern". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the introduction of the single responsibility principle and interface isolation principle in the seven design principles of java design pattern.

Overview

A brief introduction to the seven design principles:

Open-close principle: is the core of all object-oriented design, open to extensions, closed to modifications

Dependency inversion principle: programming for interfaces, relying on abstraction rather than concrete

Single responsibility principle: an interface is responsible for only one thing, and there can only be one reason for class change.

Interface isolation principle: use multiple specialized interfaces instead of one master interface

Dimitt rule (least known principle): only communicate with friends (member variables, method input and output parameters), do not talk to strangers, control access modifiers

Richter substitution principle: subclasses can expand the functions of the parent class, but can not change the original function of the parent class

Principle of synthetic reuse: try to use object composition (has-a) / aggregation (contanis-a) instead of inheritance relationship to achieve the purpose of software reuse.

Single responsibility principle definition

Single responsibility (Simple Responsibility Pinciple,SRP) means that there is no more than one cause of class change.

Suppose we have a Class responsible for two responsibilities. Once the requirements change, modifying the logical code of one responsibility may cause the function of the other responsibility to fail. In this way, there are two reasons for this Class to lead to class changes. How to solve this problem? We are going to decouple the two responsibilities with two Class respectively. Later requirements change maintenance does not affect each other. This design can reduce the complexity of the class, improve the readability of the class, improve the maintainability of the system, and reduce the risk caused by change. Generally speaking, an Class/Interface/Method is responsible for only one responsibility.

Example

Next, let's refer to the example of user information management mentioned in the Zen of Design patterns:

Create a new user information IUserInfo class:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:07 * / public interface IUserInfo {void setUserID (String userID); String getUserID (); void setPassword (String password); String getPassword (); void setUserName (String userName); String getUserName (); boolean changePassword (String oldPassword); boolean deleteUser (); void mapUser (); boolean addOrg (int orgID); boolean addRole (int roleID);}

User information maintenance class diagram:

If you design like this, even a junior programmer can see that there is something wrong with the decoupling design, and there is no separation between the user's attributes and the user's behavior. The user's information should be extracted into a BO, and the behavior should be extracted into a Biz (business logic). Then we modify the interface. Create the IUserBo class:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:18 * / public interface IUserBO {void setUserID (String userID); String getUserID (); void setPassword (String password); String getPassword (); void setUserName (String userName); String getUserName ();}

Create the IUserBiz class:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:18 * / public interface IUserBiz {boolean changePassword (String oldPassword); boolean deleteUser (); void mapUser (); boolean addOrg (int orgID); boolean addRole (int roleID);}

Class diagram after division of responsibilities:

We split IUserInfo into IUserBo and IUserBiz. We have implemented the single responsibility of the two classes, that is, to make them change for only one reason, and to aggregate the highly relevant content within the same class.

However, in actual development, we will rely on, combine, and aggregate these relationships, as well as the size, cycle, level of technicians, and schedule control of the project, many of which do not meet a single responsibility. However, in the process of writing code, we keep the interfaces and methods as single as possible, which is of great help to the maintenance later in our project.

Definition of interface isolation principle

The principle of interface isolation (Interface Segregation Principle, ISP) refers to the use of multiple specialized interfaces instead of a single master interface, and the client should not rely on interfaces it does not need. This principle instructs us to pay attention to a few points when designing interfaces:

The dependence of a class on a class should be based on the smallest interface.

Build a single interface, not a big, bloated interface.

Try to refine the interface, and there are as few methods in the interface as possible (not as few as possible, it must be moderate).

The principle of interface isolation accords with the design idea of high cohesion and low coupling, which makes the class have good readability, expansibility and maintainability. When designing the interface, we need to spend more time thinking about the business model, including some predictions that may change in the future. Therefore, for abstraction, the understanding of the business model is very important.

Example

Let's look at a piece of code and write an abstraction of animal behavior:

IAnimal interface:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:56 * / public interface IAnimal {void eat (); void fly (); void swim ();}

The Bird class implementation:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:57 * / public class Bird implements IAnimal {public void eat () {} public void fly () {} public void swim () {}}

The Dog class implementation:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:57 * / public class Dog implements IAnimal {public void eat () {} public void fly () {} public void swim () {}}

As you can see, the swim () method of Bird may only be empty, while the fly () method of Dog is obviously impossible. At this time, we design different interfaces for different animal behaviors, designing IEatAnimal,IFlyAnimal and ISwimAnimal interfaces respectively to look at the code:

IEatAnimal interface:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:59 * / public interface IEatAnimal {void eat ();}

IFlyAnimal interface:

/ * * @ author eamon.zhang * @ date 2019-09-25 5:01 * / public interface IFlyAnimal {void fly ();}

ISwimAnimal interface:

/ * * @ author eamon.zhang * @ date 2019-09-25 5:02 * / public interface ISwimAnimal {void swim ();}

Dog implements only IEatAnimal and ISwimAnimal interfaces:

/ * * @ author eamon.zhang * @ date 2019-09-25 4:57 * / public class Dog implements IEatAnimal,ISwimAnimal {public void eat () {} public void swim () {}}

Let's take a look at the comparison of the two class diagrams, which is very clear:

At this point, I believe you have a deeper understanding of the "introduction of single responsibility principle and interface isolation principle in the seven design principles of java design pattern". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.