In-depth understanding of the JavaScript series: the principle of solid five principles of interface isolation ISP (reprint)

In-depth understanding of the JavaScript series: the principle of solid five principles of interface isolation ISP
Objective

In this chapter we are going to explain the 4th of the S.o.l.i.d Five principles of JavaScript implementation, the interface isolation principle of the ISP (the Interface segregation Principle).

English Original: http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
Note: This article is written by the author more around the mouth, so the uncle understand is also more depressed, make a look at it, don't get bogged down in the

The description of the interface isolation principle is:

Clients should not being forced to depend on methods they does not use.
Customers should not be forced to rely on methods that they do not use.

When the user relies on the interface method, even if it is not used by other users, it also has to implement these interfaces, in other words, one user relies on an interface that is not used but is used by other users, when other users modify the interface, all users who rely on the interface will be affected. This clearly violates the principle of open and closed, nor is it what we expect.

Interface Isolation principle the ISP is a bit like a single responsibility, and is used to aggregate functional responsibilities, and 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 comply with this principle under JavaScript? After all, JavaScript has no interface, and if the interface is what we think it is to build contract and decoupling with the abstract type provided by some language, that's OK, but JavaScript has another form of interface. In design patterns–elements of reusable object-oriented software we found the definition of the interface:

Any action declared by an object contains an action name, a Parameter object, and the return value of the operation. We call this the signature of the operator (signature).
All operations declared in an object are called Interfaces (interface) of this object. An 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 that consists of all the properties and methods of the object. Refer to the following code:

varExamplebinder = {};
Examplebinder.modelobserver = (function() {
    /*Private Variables*/
    return{
Observefunction(model) {
            /*Code*/
            returnNewmodel;
},
OnChange:function(callback) {
            /*Code*/
}
}
})();

Examplebinder.viewadaptor = (function() {
    /*Private Variables*/
    return{
Bindfunction(model) {
            /*Code*/
}
}
})();

Examplebinder.bind =function(model) {
    /*Private Variables*/
ExampleBinder.modelObserver.onChange (/*Callback Callback*/);
    varOM = exampleBinder.modelObserver.observe (model);
ExampleBinder.viewAdaptor.bind (OM);
    returnOm
};

The functions implemented by the Examplebinder class library above are two-way binding. The public interface exposed by this class library is the Bind method, where the functions of the change notification and view interaction used in bind are implemented by separate objects Modelobserver and Viewadaptor, respectively. These objects are, in a sense, the concrete implementations of the public 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 subsections we discuss below are the implications of JavaScript for violating the principle of interface isolation. As seen above, the implementation of the interface isolation principle in JavaScript is a pity, but not as powerful as the static type language, JavaScript language features sometimes make the so-called interface a little sticky.

The realization of the fall

In a static type language language, one of the reasons 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, then other methods must be implemented (either by empty implementations or by throwing exceptions). In JavaScript, if you only need a certain interface in an object, he can't solve the problem, although it doesn't have to be forced to implement the interface above. But the implementation still violates the principle of the Richter replacement.

varRectangle = {
Areafunction() {
        /*Code*/
},
Drawfunction() {
        /*Code*/
}
};

varGeometryapplication = {
Getlargestrectangle:function(rectangles) {
        /*Code*/
}
};

varDrawingapplication = {
Drawrectangles:function(rectangles) {
       /*Code*/
}
};

When a rectangle substitute is needed to satisfy the getlargestrectangle of the new object geometryapplication, it only needs the area () method of Rectangle, But it violates the LSP (because he doesn't have the Drawrectangles method to use the Draw method).

Static Coupling

Another reason for a static type language that causes a violation of the ISP is static coupling, where the interface plays a major role in a loosely coupled design program in a statically typed language. 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 from the unrelated behavior. There is no such problem in JavaScript, because objects are decoupled by the advantages unique to dynamic language.

Semantic Coupling

A common reason for violating the ISP, both dynamic and static type languages, is semantic coupling, the so-called semantic coupling is interdependent, that is, the behavior of one object depends on another object, which means that if one user changes one of the behaviors, it is likely to affect another user. This also violates the principle of single responsibility. This problem can be resolved through inheritance and object substitution.

Scalability

Another cause of the problem is extensibility, and many people cite examples of callback to show extensibility (such as the callback settings after successful Ajax). If you want an interface like this that requires an implementation and there are a lot of familiarity or methods in the object of the implementation, then the ISP becomes very important, that is, when an interface interface becomes a requirement to implement many methods, his implementation will become extremely complex, And it is possible to cause these interfaces to assume a non-sticky duty, which is the fat interface we often mention.

Summarize

The dynamic language features in JavaScript make our non-sticky interfaces less influential than static type languages, but the interface isolation principle still has its place in JavaScript programming patterns.

Synchronization and recommendations

This article has been synchronized to the directory index: in- depth understanding of JavaScript series

In-depth understanding of the JavaScript series, including the original, translation, reprint and other types of articles, if it is useful to you, please recommend supporting a, to the power of the uncle writing.

Original link This article by Bean John Blog Backup expert remote One click release

In-depth understanding of the JavaScript series: the principle of solid five principles of interface isolation ISP (reprint)