In-depth understanding of the JavaScript Series: S.O.L.I.D principles of the Five Principles of interface isolation ISP

Preface This chapter is to explain the s.o.l.i.d Five principles of the JavaScript language implementation of the 4th, interface isolation principle 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 description of the interface isolation principle is: Clients should not being forced to depend on methods they Donot used. Customers should not be forced to rely on methods they don't 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. How do we comply with this principle under JavaScript interface 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. At design patterns–elements of reusable Object-Oriented software We found the definition of an 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{observe:function(model) {/*Code*/            returnNewmodel; }, OnChange:function(callback) {/*Code*/}} ) (); Examplebinder.viewadaptor= (function() {    /*Private Variables*/    return{bind:function(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. ISPs and JavaScript Some of the sections discussed 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 depravity 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 ={area:function() {        /*Code*/}, Draw:function() {        /*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). The other reason for static-coupled static-type language is static coupling, which 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 leads to a common cause of breach of ISP, both dynamic and static type languages, that 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 a user changes one of the behavior, There is a good chance that another user will be affected. 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 for success in 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. Summing up the dynamic language features in JavaScript makes 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 recommendation 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. 

In-depth understanding of the JavaScript Series: S.O.L.I.D principles of the Five Principles of interface isolation ISP