In-depth understanding of JavaScript series (21): Detailed explanation of the interface isolation principle ISP of the five principles of S.O.L.I.D_Basic knowledge

Foreword

What we are going to explain in this chapter is the fourth of the five principles of S.O.L.I.D JavaScript language implementation, the Interface Segregation Principle ISP (The Interface Segregation Principle).

English original text:http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
Note: The author of this article is quite convoluted, so the uncle is quite depressed when he understands it. Just read it and don’t get too deep into it
The description of the interface isolation principle is:

Copy code The code is as follows:

Clients should not be forced to depend on methods they do not use.

Clients should not be forced to rely on methods they don't use.

When a user relies on an interface method that is only used by other users but not used by itself, it must implement these interfaces. In other words, a user relies on an interface that is not used but is used by other users. When other users When this interface is modified, all users who rely on it will be affected. This obviously violates the open-closed principle and is not what we expect.

The interface isolation principle ISP is somewhat similar to single responsibility. They are both used to aggregate functional responsibilities. In fact, ISP can be understood as converting a program with a single responsibility into an object with a public interface.

JavaScript interface

How can we comply with this principle under JavaScript? After all, JavaScript does not have the characteristics of an interface. If the interface is what we want to establish a contract and decouple through an abstract type provided by a certain language, then it can be said to be okay, but JavaScript has another form of interface. In the book Design Patterns – Elements of Reusable Object-Oriented Software we find the definition of interface:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Any operation declared by an object contains an operation name, parameter object and return value of the operation. We call this the signature of the operator.
All operations declared in an object are called the object's interface. An object's interface describes all request information that occurs on this object.
Regardless of whether a language provides a separate construct to represent an interface, all objects have an implicit interface consisting of all the properties and methods of the object. Refer to the following code:

Copy code The code is as follows:

var exampleBinder = {};
exampleBinder.modelObserver = (function() {
/* Private variables */
Return {
         observe: function(model) {
                                                    /* Code */
               return newModel;
},
onChange: function(callback) {
                                                    /* Code */
}
}
})();

exampleBinder.viewAdaptor = (function() {
/* Private variables */
Return {
           bind: function(model) {
                                                    /* Code */
}
}
})();

exampleBinder.bind = function(model) {
/* Private variables */
ExampleBinder.modelObserver.onChange(/* callback */);
var om = exampleBinder.modelObserver.observe(model);
ExampleBinder.viewAdaptor.bind(om);
Return om;
};

The function implemented by the exampleBinder class library above is two-way binding. The public interface exposed by this class library is the bind method. The functions of change notification and view interaction used in bind are implemented by separate objects modelObserver and viewAdaptor respectively. In a sense, these objects are the public interface bind. The specific implementation of the method.

Although JavaScript does not provide an interface type to support the contract of an object, the implicit interface of the object can still be provided to program users as a contract.

ISP and JavaScript

Some of the sections we discuss below are about the impact of violating the interface isolation principle in JavaScript. As seen above, it is a pity to implement the interface isolation principle in JavaScript programs, but it is not as powerful as a statically typed language. The language characteristics of JavaScript sometimes make the so-called interface a bit non-sticky.

Realization of Fall

In statically typed languages, one reason for violating the ISP principle is a fallen implementation. All methods defined in interfaces in Java and C# must be implemented. If you only need a few of them, the other methods must also be implemented (either by empty implementation or by throwing an exception). In JavaScript, if you only need certain interfaces in an object, it cannot solve the problem of corrupted implementation, although there is no need to enforce the implementation of the above interfaces. But this implementation still violates the Liskov substitution principle.

Copy code The code is as follows:

var rectangle = {
Area: function() {
          /* Code */
},
Draw: function() {
          /* Code */
}
};

var geometryApplication = {
GetLargestRectangle: function(rectangles) {
          /* Code */
}
};

var drawingApplication = {
drawRectangles: function(rectangles) {
         /* Code */
}
};

When a rectangle substitute satisfies the getLargestRectangle of the new object geometryApplication, it only needs the area() method of rectangle, but it violates LSP (because it does not use the draw method that can be used by the drawRectangles method at all. ).

Static Coupling

Another reason for ISP violations in statically typed languages ​​is static coupling. In statically typed languages, interfaces play an important role in a loosely coupled design program. Whether in a dynamic language or a static language, sometimes an object may need to communicate among multiple client users (such as shared state). For statically typed languages, the best solution is to use Role Interfaces, which allows users and The object interacts (and the object may need to be in multiple roles) as its implementation decouples the user from unrelated actions. There is no such problem in JavaScript, because objects are decoupled by the unique advantages of dynamic languages.

Semantic Coupling

A common reason that leads to violations of ISP, both in dynamic languages ​​and statically typed languages, is semantic coupling. The so-called semantic coupling is mutual dependence, that is, the behavior of one object depends on another object, which means that if If one user changes one of the behaviors, it is likely to affect another user. This also violates the single responsibility principle. This problem can be solved through inheritance and object substitution.

Scalability

Another reason for the problem is scalability. Many people will give examples about callback to demonstrate scalability (such as callback settings after success in ajax). If such an interface requires an implementation and there are many familiarity or methods in the implemented object, ISP will become very important. That is to say, when an interface becomes an interface that needs to implement many methods, its The implementation will become extremely complex, and may cause these interfaces to take on a non-sticky responsibility. This is what we often refer to as fat interfaces.

Summary

The dynamic language features in JavaScript make our implementation of non-sticky interfaces less influential than statically typed languages, but the interface isolation principle still has its place in the JavaScript programming pattern.