Serialization: Object-oriented sunflower collection: thoughts, skills, and practices (33)-ISP principles

ISP, Interface segregation principle.Interface isolation principle".

Like the dip principle, the ISP principle was proposed by the famous Martin. In 1996, he published an article titled "The interface segregation principle" in C ++ reporter, which elaborated on the ISP principle, in addition, in his classic book agile software development, principles, patterns (Chinese Translation: Agile Software Development: Principles, models and practices), practices, and agile principles, patterns, and practices in C.

 

The original definition of ISP is as follows:

"Clients shocould not be forced to depend upon interfaces that they do not use ."

"Clients should not be forced to depend on interfaces they do not need ".

 

From the literal perspective, the ISP principle is the best of the five principles. However, we thought deeply and found that it was not that simple. If you still remember the principles we mentioned earlier, you may think of a question: why ISP?

 

Now let's recall the SRP principle. If the class meets the SRP principle, isn't the interface extracted based on this class naturally satisfying the ISP principle? Why is it hard for us to develop another ISP principle?

 

Master Martin will naturally not be able to get full of food and do nothing. He has explained the ISP principles in his essay in this article, unfortunately, many people did not post this sentence:

The ISP acknowledges that there are objects that require non-cohesive interfaces; However it suggests that clients shocould not know about them as a single class. Instead, clients Shocould know about abstract base classes that have cohesive interfaces.

Translation: the ISP principle recognizes that an object requires a non-cohesive interface. However, the ISP principle suggests that the client does not need to know the entire class, but only needs to know the abstract parent class with the cohesive interface.

 

That is to say,ISP application scenarios are that some classes do not meet the SRP principle. However, clients that use these classes (called classes) should use them based on interfaces instead of using them directly..

 

Despite the translation, the translation is still more abstract than just plain. It is clear to give an example, and there is already a very good example, that is, the "All-in-One Machine" in the SRP principle ".

 

In the "All-in-One Machine" example, although the "All-in-One Machine" has the "print, copy, scan, and fax" function at the same time, we do not design an "all-in-one machine" interface, instead, four interfaces are designed. In this way, the class that calls an interface can precisely use an interface as needed, rather than calling a large and complete interface.

 

The Code is as follows:

Icopier. Java

Package COM. oo. java. principles. ISP;/*** copier interface */public interface icopier {/*** copy * @ Param paper */void copy (Paper paper );}

Ifaxmachine. Java

Package COM. oo. java. principles. ISP;/*** Fax interface */public interface ifaxmachine {/*** Fax * @ Param MSG */void Fax (string MSG );}

Iprinter. Java

Package COM. oo. java. principles. ISP;/*** printer interface */public interface iprinter {/*** print * @ Param Doc */void print (document DOC );}

Iscanner. Java

Package COM. oo. java. principles. ISP;/*** scanner interface */public interface iscanner {/*** scan * @ Param paper */void scan (Paper paper );}

Multifuncprinter. Java

Package COM. oo. java. principles. ISP;/*** multi-function printer (all-in-one machine) * implements ifaxmachine, icopier, iprinter, and iscanner) four interfaces * instead of one imultifuncprinter interface, provide the functions of the above interfaces at the same time **/public class multifuncprinter implements ifaxmachine, icopier, iprinter, iscanner {@ override public void scan (Paper paper) {// todo auto-generated method stub} @ override public void print (document DOC) {// todo auto-generated method stub} @ override public void copy (Paper paper) {// todo auto-generated method stub} @ override public void Fax (string MSG) {// todo auto-generated method stub }}

People. Java

Package COM. oo. java. principles. ISP;/*** person */public class people {/*** copy operation. The copy method depends on the icopier interface, instead of using the mutifuncprinter class */Public void copy (icopier copier, paper paper) {copier. copy (paper);}/*** print operation. The print method depends on the iprinter interface, instead of using the mutifuncprinter class */Public void print (iprinter printer, document DOC) {printer. print (DOC);}/*** the fax method depends on the ifaxmachine interface, instead of using the mutifuncprinter class */Public void Fax (ifaxmachine faxer, string message) {faxer. fax (Message);}/*** scan operation. The scan method depends on the iscanner interface, instead of using the mutifuncprinter class */Public void scan (iscanner scanner, paper) {signature. scan (paper );}}

Tester. Java

Package COM. oo. java. principles. ISP; public class tester {public static void Mai (string ARGs []) {People = new people (); multifuncprinter MFP = new multifuncprinter (); // For example, the following functions use MFP as the number of workers, but they actually use different interfaces implemented by the multifuncprinter class. copy (MFP, new paper (); // use the icopier interface of the multifuncprinter class, people. fax (MFP, "I Love oo"); // use the ifaxmachine interface of the multifuncprinter class, people. print (MFP, new document (); // use the iprinter interface of the multifuncprinter class, people. scan (MFP, new paper (); // use the iscanner interface of the multifuncprinter class ,}}