Deep understanding of the JavaScript Series: S.O.L.I.D principles of the interface isolation principle ISP Detailed _ Basics

Objective

In this chapter, we will explain the 4th S.O.L.I.D of the Five Principles JavaScript language implementation, the interface isolation principle ISP (the Interface segregation principle).

Original English: http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
Note: The author of this article is more around the mouth, so the uncle understand is also more depressed, make up to see, don't get bogged down in the
The description of the interface isolation principle is:

Copy Code code as follows:

Clients should is forced to depend on methods.

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

When a user relies on an interface method that is not used by another user, it also has to implement these interfaces, in other words, one user relies on an interface that is not used but is used by another user, and all users who depend on that interface will be affected when other users modify the interface. This is a clear violation of the principle of opening and closing, nor is it what we expect.

Interface Isolation principle the ISP is similar to a single responsibility for aggregating functional responsibilities, in fact the ISP can be understood to have a single responsibility of the program into a public interface object.

JavaScript interface

How do we follow this principle in JavaScript? After all, JavaScript has no interface characteristics, and if the interface is what we think of as an abstract type provided by a language to create contract and decoupling, that's OK, but JavaScript has another form of interface. In the design patterns–elements of reusable object-oriented software, we found the definition of an interface:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Any action declared by an object contains an action name, a Parameter object, and the return value of the operation. We call it the operator's signature (signature).
All operations declared in an object are called interfaces of this object (interface). The interface of an object depicts all the 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 code 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 callback * *);
var om = exampleBinder.modelObserver.observe (model);
ExampleBinder.viewAdaptor.bind (OM);
Return om;
};

The Examplebinder class library above implements the functionality of bidirectional binding. The public interface exposed by this class library is the Bind method, where the function of the change notification and view interaction used in BIND is implemented by separate objects Modelobserver and Viewadaptor respectively, These objects are, in a sense, the concrete implementation of the common interface bind method.

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

ISP and JavaScript

Some of the sections we discuss below are the effects of JavaScript on violating the principle of interface isolation. As you can see above, the implementation of the interface isolation principle in a JavaScript program is a pity, but not as powerful as a static type of language, which sometimes makes the so-called interface a little sticky.

The realization of the fall

In statically typed languages, one reason for violating ISP principles is the realization of depravity. The methods defined in all interfaces in Java and C # must be implemented, and if you only need a few of them, the other methods must be implemented (either by null implementations or by throwing exceptions). In JavaScript, if you only need a certain interface in an object, he can not solve the problem of corruption, although not forced to implement the above interface. But the implementation still violates the principle of the Richter substitution.

Copy Code code 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 to meet the getlargestrectangle of the new object geometryapplication, it only needs the rectangle area () method, But it violates LSP (because he does not use the Draw method in which the Drawrectangles method is used).

Static coupling

Another reason for violating ISPs in the static type language is static coupling, where interfaces play a significant role in a loosely coupled design program in statically typed languages. Whether in a dynamic language or in a static language, sometimes an object may need to communicate with multiple client users (such as shared state), and the best solution for statically typed languages is to use role interfaces, It allows the user to interact with the object (and the object may need to be in multiple roles) as its implementation to decouple the user and extraneous behavior. In JavaScript there is no such problem, because objects are decoupled by the virtues peculiar to the dynamic language.

Semantic coupling

A common cause that violates the ISP, both dynamic and static type languages, that is, semantic coupling, the so-called semantic coupling is interdependent, that is, the behavior of an object depends on another object, which means that if a user changes one of the behaviors, it is likely to affect another user. It also violates the principle of sole responsibility. This problem can be solved by inheritance and object substitution.

Scalability

Another cause of the problem is scalability, and a lot of people cite examples of callback to show scalability (such as the callback settings that are successful in Ajax). If an interface like this requires an implementation and there are a lot of familiarity or methods in the object of the implementation, the ISP becomes very important, which means that when an interface interface becomes a requirement to implement many methods, his implementation becomes extraordinarily complex, And it is possible that these interfaces assume a duty without stickiness, which is the fat interface we often refer to.

Summarize

The dynamic language features in JavaScript allow us to realize the influence of the non viscous interface is smaller than the static type language, but the interface isolation principle still has its function in JavaScript programming mode.