Design Patterns-six principles-interface isolation principles

First, let's take a look at the definition of the interface isolation principle. There are two definitions.

First: clients shocould not be forced to depend upon interfaces that they don't use. (the client should not force the interface it does not need)

Type 2: the dependency of one class to another one shoshould depend on the smallest possible interface. (dependencies between classes should be built on the smallest Interface)

 

The interface here is not only an interface defined by the interface keyword. There are two types of interfaces:

1. object interface)

A class declared in Java is an instance generated by the new keyword. It is a description of a type of thing, which is also an interface. For example:

Phone phone = new phone (); here the class person is an interface of the Instance phone

2. Class Interface)

This interface is defined through the interface keyword.

 

That is to say, the interface isolation principle requires that a module only depends on the interfaces it needs to ensure the purity of interfaces. It is also necessary to ensure that the interface should be as small as possible, that is, the interface should be refined as much as possible when designing the interface, and do not define too bloated interfaces (for example, the interface has many irrelevant logic method declarations ).

The interface isolation principle is similar to the single responsibility principle, but the difference is that the single responsibility principle requires a single class and interface responsibility, focuses on the responsibility, and is the division of business logic. The interface isolation principle requires that the interface methods should be as few as possible and as useful as possible (for a module)

 

When using the interface isolation principle, some specifications are required:

1. The interface should be as small as possible

The interface should be as small as possible to ensure that an interface serves only one sub-module or business logic

2. High Cohesion of interfaces

High Cohesion of interfaces is highly dependent on internal systems and is isolated from external systems as much as possible. That is, the declared methods in an interface are related to a sub-module and are required by this sub-module.

3. Limited Interface Design

However, if you fully follow the interface isolation principle, a problem may occur. That is to say, the interface design will be smaller and smaller, which leads to a sharp increase in the number of interfaces and an increase in system complexity, which is not required by real projects, therefore, when using this principle, it is necessary to judge based on experience or attempt in a specific project, but there is no fixed standard.

 

For example

Shopping on chunxi road is full of women. There are big moms wearing stockings (disgusting), quiet girls, and sexy hot girls. In short, there are many women. However, when you say "Beauty, money is lost" to the front, it is estimated that you are calling yourself. Nowadays, the word "beauty" has become popular. She said "beauty" when she greets her. But is the real beauty like this? The beauty in male's mind should be like this: good shape, good looks, and good temperament.

Iprettygirl. Java: defines beauty standards

// Define the beauty interface public interface iprettygirl {// public void greatlooks (); // public void greatfigure (); // public void greattemperament ();}

Prettygril. Java: implements the beauty class

Public class prettygirl implements iprettygirl {private string name; // constructor, beauty name public prettygirl (string name) {This. name = Name;} // body @ overridepublic void greatfigure () {system. out. println (name + ": Very tall");} // nice looks @ overridepublic void greatlooks () {system. out. println (name + ": looks very good");} // temperament @ overridepublic void greattemperament () {system. out. println (name + ": Excellent temperament ");}}

Aman: an abstract class that abstracts a man.

Public abstract class Aman {protected iprettygirl prettygirl; Public Aman (iprettygirl prettygirl) {This. prettygirl = prettygirl;} // handsome guy starts looking for a beautiful girl. Public abstract void findgirl ();}

MAN:

Public class man extends Aman {public man (iprettygirl prettygirl) {super (prettygirl) ;}@ overridepublic void findgirl () {system. out. println ("Beauty here: ----------------------"); super. prettygirl. greatlooks (); super. prettygirl. greatfigure (); super. prettygirl. greattemperament ();}}

Scenario, chunxi Road, handsome guy started looking for beautiful women

Public class chunxiroad {public static void main (string ARGs []) {iprettygirl Jiajia = new prettygirl ("Jia"); Aman man = new man (Jiajia); man. findgirl ();}}

Running result:

Beauty here :----------------------
Jia: looks very good.
Jia: Very tall
Jia: Excellent temperament

But there is a problem here, the interface is not very clear, for example, some men think that some girls look good, good is beautiful (regardless of the quality of this girl, for example, the "pulse belt "). Although some girls look general and have a general body, they are very good temperament. This is the temperament beauty of some otaku, or the three have it. Therefore, the interface should be further divided to meet the aesthetics of different men.

We divide interfaces into two types:

Good shape

Public interface igreatbody {// public void greatlooks (); // public void greatfigure ();}

Good temperament

Public interface igreattemperament {// public void greattemperament ();}

 

Then we can find the beauty that we think we need. For example

The preceding Aman and man interfaces are changed to igreatbody.

Next, we came to Tokyo. I saw instructor Cang.

Public class Tokyo {public static void main (string ARGs []) {igreatbody canglaoshi = new prettygirl ("Cang "); Aman man = new man (canglaoshi); man. findgirl ();}}

Running result:

Beauty here :----------------------
Instructor Cang: looks very good.
Instructor Cang: He is very tall.