In-depth understanding of the JavaScript series (21): Five Principles of S.O.L. I. D: interface isolation principle ISP _ basic knowledge

This article mainly introduces the JavaScript series (21): S.O.L. i. the five principles of D: interface isolation principle ISP details. This article describes JavaScript interfaces, ISP and JavaScript, fallen implementations, static coupling, semantic coupling, scalability, and so on, for more information, see Preface

In this chapter, we will explain 4th of The five principles S.O.L. I. D implemented by The JavaScript language, and The Interface isolation Principle ISP (The Interface Segregation Principle ).

Http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/.
Note: The author of this article is a bit difficult to understand, so uncle is also quite depressed. let's take a look. don't get stuck.
The interface isolation principle is described as follows:

The code is as follows:

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

Customers should not be forced to rely on methods they do not need.

If the interface method that the user depends on is used only by other users and does not need to use it, it must implement these interfaces. In other words, A user depends on interfaces that are not used but used by other users. when other users modify this interface, all users dependent on this interface will be affected. This clearly violates the open and closed principle and is not what we expect.

The interface isolation principle is similar to that of a single role. it is used to aggregate function responsibilities. In fact, an ISP can be understood to convert a program with a single role to an object with a public interface.

JavaScript interface

In JavaScript, how should we observe this principle? After all, JavaScript has no interface features. if the interface is what we want to establish contract and decoupling through the abstract types provided by a language, it can be said that it is okay, however, JavaScript has another form of interface. In the book Design Patterns-Elements of Reusable Object-Oriented Software, we found the interface definition:
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 Operation return value. We call it the signature of the operator ).
All the operations declared in an object are called interfaces of this object ). An object interface depicts all request information that occurs on this object.
No matter whether a language provides a separate structure to represent interfaces, all objects have an implicit interface consisting of all attributes and methods of the object. Refer to the following code:

The code is as follows:

Var exampleBinder = {};
ExampleBinder. modelObserver = (function (){
/* Private variable */
Return {
Observe: function (model ){
/* Code */
Return newModel;
},
OnChange: function (callback ){
/* Code */
}
}
})();

ExampleBinder. viewAdaptor = (function (){
/* Private variable */
Return {
Bind: function (model ){
/* Code */
}
}
})();

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

The preceding exampleBinder class library implements bidirectional binding. The public interface exposed by this class library is the bind method. The change notification and view interaction functions used in the bind are implemented by the independent object modelObserver and viewAdaptor respectively, in a sense, these objects are the concrete implementation of the common interface bind method.

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

ISP and JavaScript

The following sections discuss the impact of violations of interface isolation principles in JavaScript. As we can see above, it is a pity to implement the interface isolation principle in JavaScript programs, but it is not as powerful as the static type language. The Language features of JavaScript sometimes make the so-called interfaces a little non-stick.

Degraded implementation

In a static language, one reason for violating the ISP principle is the degraded implementation. The methods defined in all interfaces in Java and C # must be implemented. if you only need a few of them, other methods must also be implemented (empty implementation or exception throwing can be used ). In JavaScript, if you only need some interfaces in an object, he cannot solve the problem of downgrading implementation, although he does not need to implement the above interface forcibly. However, this implementation still violates the Lee's replacement principle.

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 alternative is used to meet the getLargestRectangle of the new geometryApplication object, it only needs the area () method of rectangle, but it violates the LSP (because it does not use the draw method that is used by the drawRectangles method ).

Static coupling

Another reason for violation of ISP in static language is static coupling. in static language, interfaces play a major role in a loosely coupled design program. Whether in a dynamic or static language, sometimes an object may need to communicate with users on multiple clients (such as the shared state, the best solution is to use Role Interfaces, which allows users to interact with the object (and the object may need to be in multiple roles) as its implementation, it decouples user and irrelevant behaviors. This problem does not occur in JavaScript, because objects are decoupled by the unique advantages of dynamic languages.

Semantic coupling

One common cause of ISP violation is that both dynamic and static languages have semantic coupling, and semantic coupling is mutual dependency, that is, the behavior of an object depends on another object, which means that if a user changes one of the actions, 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 cause is the Scalability. many people will give callback examples to demonstrate scalability (for example, callback settings after ajax is successful ). ISP will become very important if you want to implement such an interface and there are many familiar or methods in the implementation object, that is to say, when an interface becomes a requirement to implement many methods, its implementation will become abnormal and complex, and may lead to these interfaces to assume a non-sticky responsibility, this is the fat interface we often mention.

Summary

The dynamic language features in JavaScript make our implementation of non-viscous interfaces less influential than static languages, but the interface isolation principle still plays a role in JavaScript programming patterns.