In-depth understanding of the Javascript series (22): s.o.l. I. d five principles-Dependency inversion principle dip

Preface

In this chapter, we will explain 5th of the Five Principles of s.o.l. I. d implemented by the Javascript language and the dependency inversion principle LSP (the Dependency inversion principle ).

 
Http://freshbrewedcode.com/derekgreer/2012/01/22/solid-javascript-the-dependency-inversion-principle/.
 

Dependency inversion principle

The dependency inversion principle is described as follows:

 
A. High-level modules shocould not depend on low-level modules. Both shold depend on each actions.
High-level modules should not depend on low-level modules, both of which should depend on abstraction.

B. Define actions shocould not depend upon details. Details shocould depend upon login actions.
Abstraction should not depend on details, and details should depend on abstraction
 

The most important issue of the dependency inversion principle is to ensure the applicationProgramOr the main components of the framework are decoupled from the Implementation Details of non-important underlying components, which will ensure that the most important part of the program will not be affected by the changes in the low-level components.

The first part of this principle is about the coupling between the high-level module and the low-level module. In the traditional divided architecture, the high-level module encapsulates the core business logic of the program) it depends on some lower-layer modules (some basic points ). When the Dependency inversion principle is applied, the relationship is reversed. Unlike the higher-level modules, the dependency inversion enables the lower-level modules to depend on the interfaces defined in the higher-level modules. For example, if data persistence is required for a program, the traditional design is that the core module depends on the API of a persistence module. After Reconstruction Based on the Dependency inversion principle, the core module needs to define the persistent API interface, and then the persistent implementation instance needs to implement the API interface defined by the core module.

The second part of this principle describes the correct relationship between abstraction and details. Understanding this part is helpful by understanding the C ++ language, because it has obvious applicability.

Unlike some static languages, C ++ does not provide a language-level concept to define interfaces. What is the difference between class definition and class implementation? In C ++, classes are defined in the form of header files, which define the class member methods and variables to be implemented by the source files. Because all the variables and private methods are defined in the header file, they can be used to abstract and decouple from the implementation details. You can define only abstract methods to implement (C ++ is an abstract base class) interfaces for implementing classes.

Dip and JavaScript

Javascript is a dynamic language, so it does not need to be abstracted for decoupling. Therefore, abstraction should not depend on the details. This change does not have much impact on JavaScript, but the high-level module should not depend on the lower-level module, but it has a great impact.

When the Dependency inversion principle is discussed in the context of static language, the concept of coupling includes two types: semantic and physical. That is to say, if a high-level module depends on a low-level module, that is, it is coupled with both semantic interfaces and physical interfaces defined in the underlying module. That is to say, the high-level module should not only be decoupled from the third-party class library, but also from the original low-level module.

To explain this, imagine a. Net program may contain a very useful high-level module, which relies on a low-level persistence module. When the author needs to add a similar interface to the persistent API, whether or not the Dependency inversion principle is used, the high-level module cannot be reused in other programs before it implements the new interface of this low-level module.

In JavaScript, the applicability of the dependency inversion principle is limited to semantic coupling between high-level modules and lower-level modules. For example, dip can add interfaces as needed rather than coupling the implicit interfaces defined by lower-level modules.

To understand this, let's take a look at the following example:

$. FN. trackmap = Function (Options ){
 VaR Defaults = {
 /*  Ults  */ 
};
Options = $. Extend ({}, defaults, options );

 VaR Mapoptions = {
Center:New Google. Maps. latlng (options. Latitude, options. longbench ),
Zoom: 12,
Maptypeid: Google. Maps. maptypeid. Roadmap
},
Map = New Google. Maps. Map ( This [0], mapoptions ),
Pos = New Google. Maps. latlng (options. Latitude, options. longpolling );

 VaR Marker = New Google. Maps. Marker ({
Position: POs,
Title: Options. title,
Icon: Options. icon
});

Marker. setmap (MAP );

Options. Feed. Update ( Function (Latitude, longpolling ){
Marker. setmap ( Null );
 VaR Newlatlng = New Google. Maps. latlng (latitude, longpolling );
Marker. Position = newlatlng;
Marker. setmap (MAP );
Map. setcenter (newlatlng );
});

Return   This ;
};

 VaR Updater = ( Function (){
 //  Private Properties  
 
 Return {
Update: Function (Callback ){
Updatemap = callback;
}
};
})();

$ ("# Map_canvas"). trackmap ({
Latitudes: 35.044640193770725,
Longpolling:-89.98193264007568,
Icon: 'http: // bit. ly/zjngde ',
Title: 'tracking number: 100 ',
Feed: Updater
});

InCodeA small JS class library converts a div into a map to display the position information of the current trail. The trackmap function has two dependencies: a third-party Google Maps API and location feed. This feed object is responsible for calling a callback (provided during initialization) when the icon position is updated and passing in latitude and precision longpolling. Google Maps APIs are used to render interfaces.

The interface of the feed object may be designed according to the loading or the requirements of the trackmap function. In fact, his role is very simple and focuses on different simple implementations, it does not need to be so dependent on Google Maps. Google Maps API is coupled in trackmap semantics. If you need to switch to different map providers, You have to rewrite the trackmap function to adapt to different providers.

To flip the semantic coupling of the Google Maps class library, we need to rewrite the trackmap function to perform semantic coupling on an implicit interface (abstracted from the interface of the map provider, we also need an implementation object adapted to the Google Maps API. The following is the reconstructed trackmap function:

$. FN. trackmap = Function (Options ){
 VaR Defaults = {
 /*  Ults  */ 
};

Options = $. Extend ({}, defaults, options );

Options. provider. showmap (
 This [0],
Options. Latitude,
Options. longpolling,
Options. Icon,
Options. Title );

Options. Feed. Update ( Function (Latitude, longpolling ){
Options. provider. updatemap (latitude, longpolling );
});

 Return   This ;
};

$ ("# Map_canvas"). trackmap ({
Latitudes: 35.044640193770725,
Longpolling:-89.98193264007568,
Icon: 'http: // bit. ly/zjngde ',
Title: 'tracking number: 100 ',
Feed: Updater, 
 Provider: trackmap. googlemapsprovider 
});

In this version, we re-designed the trackmap function and a required map provider interface, and moved the implementation details to a separate googlemapsprovider component, this component may be encapsulated into a separate JavaScript module. The following is my googlemapsprovider implementation:

Trackmap. googlemapsprovider = ( Function (){
 VaR Marker, map;

 Return {
Showmap: Function (Element, latitude, longpolling, icon, title ){
 VaR Mapoptions = {
Center: New Google. Maps. latlng (latitude, longpolling ),
Zoom: 12,
Maptypeid: Google. Maps. maptypeid. Roadmap
},
Pos = New Google. Maps. latlng (latitude, longpolling );

Map = New Google. Maps. Map (element, mapoptions );

Marker = New Google. Maps. Marker ({
Position: POs,
Title: title,
Icon: icon
});

Marker. setmap (MAP );
},
Updatemap: Function (Latitude, longpolling ){
Marker. setmap ( Null );
 VaR Newlatlng = New Google. Maps. latlng (latitude, longpolling );
Marker. Position = newlatlng;
Marker. setmap (MAP );
Map. setcenter (newlatlng );
}
};
})();

After the above changes, the trackmap function will become very flexible and does not have to rely on Google Maps API. On the contrary, other map providers can be replaced at will, that is to say, you can adapt to any map provider as needed.

When is dependency injection?

In fact, the concept of dependency injection is often mixed with the Dependency inversion principle. To clarify this difference, we need to explain:

Dependency injection is a special form of inversion control. inversion means how a component gets its dependencies. Dependency injection means that the dependency is provided to the component, rather than the component to obtain the dependency. It means to create a dependent instance and request the dependency through the factory, request this dependency through service locator or component initialization. The dependency inversion principle and dependency injection both focus on dependencies and are used for inversion. However, the dependency inversion principle does not focus on how components obtain dependencies, but on how the high-level modules are decoupled from the lower-level modules. In a sense, the dependency inversion principle is another form of control inversion, where the module definition interface is reversed (from the lower layer to the higher layer ).

Summary

This is the last article of the five principles. In these five texts, we can see how solid is implemented in JavaScript, different principles are illustrated in Javascript from different perspectives. (Uncle note: in fact, he thinks that although it is a bit nondescribable, the general principle is the same in different languages .)

Transferred from: Uncle Tom