PHP Object-oriented Five principles of the interface Isolation principle (ISP) detailed

This article mainly introduces the PHP object-oriented interface isolation principle (ISP), detailed analysis of the concept of interface isolation, principles, use of methods and related operational considerations, the need for friends can refer to the following

In this paper, the principle of interface Isolation (ISP) of PHP object-oriented Five principles is described. Share to everyone for your reference, as follows:

When designing an application, if a module contains multiple sub-modules, then we should be careful to abstract the module. Imagine that the module is implemented by a class, and we can abstract the system into an interface. However, to add a new module extender, if the module to be added contains only some of the sub-modules in the original system, then the system will force us to implement all the methods in the interface, and needy to write some dumb methods. Such an interface is called a fat interface or contaminated interface, the use of such interfaces will introduce some improper behavior to the system, these improper behavior may lead to incorrect results, may also import resource waste.

1. Interface Isolation

The interface isolation principle (Interface segregation Principle, ISP) indicates that the client should not be forced to implement some interfaces that they will not use, should group the methods in the Fat interface, and then replace it with multiple interfaces, each serving a submodule. To put it simply, it is much better to use multiple specialized interfaces than to use a single interface.

The main points of view of ISP are as follows:

1) The dependency of a class on another class should be based on the smallest interface.

ISPs can achieve the ability to not force customers (using methods of interfaces) to rely on methods that they do not use, and the implementation classes of the interfaces should only be presented as roles of a single responsibility (following the SRP principle)

ISPs can also reduce the interplay between customers---when a customer asks for new responsibilities (changes are needed) and forces the interface to change, the likelihood of affecting other client programs is minimal.

2) The client program should not rely on an interface method (function) that it does not need.

The client program should depend on the interface method (function) It does not need, what does it depend on? Depends on the interface it needs. What interface the client needs is to provide what interface, remove the unwanted interface, which requires the interface refinement, to ensure its purity.

For example, when inheriting, because subclasses inherit all available methods from the parent class, some methods in the parent class may not be needed in subclasses. For example, regular employees and managers are inherited from the employee interface, and the employee needs to write the logbook every day, and the manager does not need it. Therefore, it is not possible to use the logbook to manager, that is, managers should not rely on the method of submitting work logs.

As you can see, the ISP and the SRP are conceptually cross-bound. In fact, many design patterns are conceptually cross-cutting, and it's even difficult to tell which design pattern a piece of code belongs to.

The ISP emphasizes that the less the interface is committed to the client, the better, and the more exclusive. When the requirements of one client program change, forcing the interface to change, the likelihood of affecting other client programs is small. This is actually the problem of interface pollution.

2. Contamination of the interface

An overly bloated interface is designed to pollute the interface. The so-called interface pollution is to add unnecessary responsibilities for the interface, if the developer in the interface to add a new feature is only to reduce the number of interface implementation classes, this design will cause the interface is constantly "polluted" and "fat".

"Interface Isolation" is actually the principle of customized service design. Using the multiple inheritance of the interface to implement a combination of different interfaces, so as to provide a combination of external functions---to achieve "on-demand services."

The interface is to be disassembled, but not too thin, this has to have a standard, this is high cohesion. Interface should have some basic functions, can only complete a basic task.

In the actual application, you will encounter the following problems: For example, I need a DAO implementation that can adapt to a variety of database, then the first one should implement a database operation interface, which stipulates some basic methods of database operation, such as connecting database, adding and pruning, shutting down the database and so on. This is a least-functional interface. For some MySQL in the special and other database does not exist or the nature of different methods, such as PHP may be used in the Pconnect method of MySQL, the other database does not exist and this method of the same concept, this method should not appear in this basic interface, So what are the basic methods of this basic interface? PDO has told you about it.

PDO is an abstract database interface layer that tells us what basic methods a basic database operator interface should implement. Interface is a high-level abstraction, so the methods in the interface should be universal, basic, not easy to change.

There is one more question, how should those unique methods be implemented? According to the ISP principle, these methods can exist in one interface, allowing the "heterogeneous" to implement both interfaces at the same time.

For the contamination of the interface, these two treatments can be considered:

Separates interfaces with delegates.

Separate interfaces with multiple inheritance.

In the delegate mode, there are two objects that participate in processing the same request, and the object that accepts the request delegates the request to another object, such as policy mode, proxy mode, etc., which are applied to the concept of the delegate.

Take a look at the example description

Have you ever met a very "fat" interface?

For example: There is an animal-related interface with the following code:

<?phpinterface animal{public  function Walk ();  Public function speak ();}

A dog is a concrete implementation of this interface:

<?phprequire_once "animal.php"; class Dog implements animal{public  function Walk () {    echo "dogs can walk";  } public  function speak () {    echo "dogs can Speak";}  }

OK, now we want to create a fish, it can swim, how to do? We have to modify the interface and also affect the implementation of the dog class, and fish needs to implement the walk and speak methods, as shown in the following code:

Animal Interface class:

<?phpinterface animal{public  function Walk ();  Public function speak ();  Public function Swim ();}

Dog class:

<?phprequire_once "animal.php"; class Dog implements animal{public  function Walk () {    echo "dogs can walk";  } public  function speak () {    echo "dogs can speak";  }  Public Function Swim () {  }}

Fish Category:

<?phprequire_once "animal.php"; class Fish implements animal{public  function Walk () {  }  Public function speak () {  } public  function swim () {    echo "fish can Swim";  }}

At this point the animal interface class presents the feature of the "Fat" interface. The so-called fat interface is actually defined in the interface is not all the implementation of the required methods, like the animal interface class, some animals can not swim, some animals will not walk, and some animals will not fly. If these methods are written in a animal interface class, then later extensions and maintenance can be a disaster.

So, how to solve the above problem?

Very simple, interface refinement, the animal interface class is split into three interface classes:

Animalcanwalk Interface class:

<?phpinterface animalcanspeak{public  function speak ();}

Animalcanswim Interface class:

<?phpinterface animalcanswim{public  function Swim ();}

Animalcanspeak Interface class:

<?phpinterface animalcanspeak{public  function speak ();}

After defining these interface classes, the implementation of dog and fish is much easier,

<?phprequire_once "animalcanspeak.php"; require_once "animalcanwalk.php"; class Dog implements Animalcanspeak, animalcanwalk{Public  function Walk () {    echo "dogs can Walk";  }  Public Function speak () {    echo "dogs can Speak";}  }

<?phprequire_once "animalcanswim.php"; class Fish implements animalcanswim{public  function Swim () {    echo] Fish can Swim ";  }}

To summarize:

The concept of the Interface isolation principle (Interface segregation Principle, ISP): use multiple specialized interfaces instead of a single total interface, that is, the client should not rely on interfaces that it does not need.

In the use of interface isolation principle, we need to pay attention to the granularity of the control interface, the interface can not be too small, if too small will lead to the system interface flooding, not conducive to maintenance, the interface can not be too large, too large interface will violate the principle of interface isolation, flexibility is poor, use is very inconvenient. In general, interfaces only contain methods that are customized for a particular class of users and should not force customers to rely on methods that they do not use.