Object-oriented programming has its own characteristics and principles, if for some understanding of object-oriented words, the three characteristics of object-oriented, encapsulation, inheritance, polymorphism, if for these three concepts do not understand, please refer to the three objects of the face basic features (javaScript).
Single Responsibility:
If we in the preparation of the program, a class or a method which contains too many methods for code readability, it is nothing more than a disaster for us. So in order to solve this problem, there has been a single responsibility.
What is the single responsibility?
Single responsibility: also known as single responsibility principle, one of the basic principles of object-oriented five (SOLID). It provides for a class should be only one reason for changes. (Adapted from Baidu Encyclopedia)
According to the above said, it is for a class, it should be the cause of it is just a change. In other words, a class of functions to a single, only the things associated with it. Designed in the design process of the class Yaoan duties remain orthogonal to each other, they interfere with each other.
Benefits of Single Responsibility
- Reduced complexity class, achieve what responsibilities are clear and unambiguous definitions
- Improve readability, reduce complexity, improve readability course
- Improve maintainability, improve readability, it is certainly easier to maintain the
- Risk reduction due to the change, the change is essential if the single interface functions well, only one interface to modify the corresponding implementation class impact, no impact on other interfaces, this scalability of the system, maintenance We have a very big help.
Example:
class ShoppinCar {
constructor(){
this.goods = [];
}
addGoods(good){
this.goods = [good];
}
getGoodsList(){
return this.goods;
}
}
class Settlement {
constructor(){
this.result = 0;
}
calculatePrice(list,key){
let allPrice = 0;
list.forEach((el) => {
allPrice += el[key];
})
this.result = allPrice;
}
getAllPrice(){
return this.result;
}
}
There are two methods for using the above code and ShoppinCar class addGoods getGoodsList, are added and the acquired commodity product list.
There are two methods calculatePrice and getAllPrice Settlement classes are doing is to calculate the total price of the acquisition price.
ShoppinCar and Settlement are doing their own thing. Add items and calculate the price, although the business is interdependent, but with two classes in the code, they do their own thing, respectively. Any changes will not make changes to a class of another class.
Open Closed Principle
In a class exposes a method to go, if the method is changed, it will have a huge effect, may lead to other rely on this method and there is no need to change the business causing widespread paralysis. To solve this problem, a method may write a single, if this method is interdependent with the other methods in this class.
Solution:
- Wherein the copy-dependent code to a new class.
- Method old class references in the new class.
Neither approach is the best solution.
The first method will lead to a large number of repeating codes, the second method will lead to interdependence between classes.
What is the principle of open and closed?
Open Closed Principle: "software objects (classes, modules, functions, etc.) should be open for extension, but for modifications is closed", which means that an entity is not allowed to change it change its behavior under the premise of the source code. (Adapted from Baidu Encyclopedia)
opening and closing principle be open for extension, but closed for modification, that does not mean without any modifications, changes the underlying module, must have high-level modules coupled to, or is an isolated meaningless snippets. Opening and closing principle is a basic principle, the other six principles are the principles of opening and closing of specific forms, methods and tools to guide the design, and the opening and closing principle is the spiritual leader.
The benefits of the principle of opening and closing
- Opening and closing principle is conducive to unit test
- Open Closed Principle can improve reusability
- Open Closed Principle can improve the maintainability
- Object-oriented development requirements
Example:
class Drag {
down(){
// ...
}
move(){
// ...
// 对拖拽没有做任何限制可以随意拖拽
}
up(){
// ...
}
}
class LimitDrag extends Drag {
move(){
// ...
// 重写该方法对拖拽进行限制处理
}
}
Rewrite the move method in LimitDrag, if modified to meet two requirements, one is restrictive drag, drag one is not restrictive, any changes to another can still operate normally.
Richter replacement
Each developer components when using someone else's, just know that the external interface components exposed, and that it is a collection of all the action, as in the end is how to achieve internal and can not know, do not need to know.
So, for the user, it can only achieve their expectations through the interface, if the component interface provides the user's behavior does not match expectations, the error will be produced. Richter substitution principle is to avoid behavior inconsistent with the derived class and the base class appears at design time.
What is the Richter replacement?
Richter substitution principle: OCP as a high-level principles of OO, advocates the use of "abstraction (Abstraction)" and "polymorphism (Polymorphism)" The design of the static structure to a dynamic structure, designed to maintain closed .
"Abstract" is the language provides. "Polymorphic" realized by the semantics of inheritance. (Adapted from Baidu Encyclopedia)
Richter replacement benefits
- Code-sharing, reduce the workload of the class is created, each subclass has methods and properties of the parent class
- Improve code reusability
- Subclass can shape the parent class, but it is different from the parent class.
- Scalability code, the parent implementation of the method can be used. Many open-source framework for expansion interface is done by inheriting the parent class.
- Improve the openness of the product or project
Example:
// 抽象枪类
class AbstractGun {
shoot(){
throw "Abstract methods cannot be called";
}
}
// 步枪
class Rifle extends AbstractGun {
shoot(){
console.log("步枪射击...");
}
}
// 狙击枪
class AUG extends Rifle {
zoomOut(){
console.log("通过放大镜观察");
}
shoot(){
console.log("AUG射击...");
}
}
// 士兵
class Soldier {
constructor(){
this.gun = null;
}
setGun(gun){
this.gun = gun;
}
killEnemy(){
if(!this.gun){
throw "需要给我一把枪";
return;
}
console.log("士兵开始射击...");
this.gun.shoot();
}
}
// 狙击手
class Snipper extends Soldier {
killEnemy(aug){
if(!this.gun){
throw "需要给我一把枪";
return;
}
this.gun.zoomOut();
this.gun.shoot();
}
}
let soldier = new Soldier();
soldier.setGun(new Rifle());
soldier.killEnemy();
let snipper = new Snipper();
// 分配狙击枪
snipper.setGun(new AUG());
snipper.killEnemy();
snipper.setGun(new Rifle());
// snipper.killEnemy(); // this.gun.zoomOut is not a function
The code can be seen from the above, the relationship between the child and parent classes, subclasses method must be equal to or greater than the parent class. Parent subclass can arise not be able to appear, but the place subclass the parent class appears certain to appear.
Dependency Inversion
If the method or methods and between class and class, there are too many dependencies will lead to poor code readability and maintainability. Dependency Inversion principle can solve these problems.
What is the Dependency Inversion?
Dependency Inversion Principle: The program depends on the abstract interface, do not depend on the specific implementation. Simply put, it is to ask for an abstract program, not to achieve programming, thus reducing the coupling between the client and the implementation module. (Adapted from Baidu Encyclopedia)
High-level modules should not depend on low-level modules, both of which should rely on abstract
abstract should not depend on the details of
the details should depend abstract
Dependency Inversion benefits:
- By relying on the interface, the implementation class isolation
- Low-level changes will not lead to higher-level change
- Improved fault tolerance code, scalability and ease of maintenance
examples:
// 抽象枪类
javascript
class AbstractGun {
shoot(){
throw "Abstract methods cannot be called";
}
}
// 步枪
class Rifle extends AbstractGun {
shoot(){
console.log("步枪射击...");
}
}
// 狙击枪
class AUG extends AbstractGun {
shoot(){
console.log("AUG射击...");
}
}
As can be seen from the above code, and sniper rifles are all dependent on the shoot guns AbstractGun abstract class, said program meets the Dependency Inversion Principle.
Interface Segregation
What is the interface isolation?
Interface Isolation: The client should not rely on it does not interface; a dependency on another class of the class should be based on the smallest interface. (Adapted from Baidu Encyclopedia)
Interface segregation principle with the new perspective of the principle of single responsibility is not the same. Single responsibility principle requires a single class responsibilities and interfaces, focusing on the role, which is divided on the business logic. The method of claim Interface interface segregation principle as little as possible.
Interface isolation benefits:
- Avoid contamination Interface
- Increase flexibility
- Provide customized services
- Achieve high cohesion
Example:
function mix(...mixins) {
class Mix {}
for (let mixin of mixins) {
copyProperties(Mix, mixin);
copyProperties(Mix.prototype, mixin.prototype);
}
return Mix;
}
function copyProperties(target, source) {
for (let key of Reflect.ownKeys(source)) {
if ( key !== "constructor"&& key !== "prototype"&& key !== "name") {
let desc = Object.getOwnPropertyDescriptor(source, key);
Object.defineProperty(target, key, desc);
}
}
}
class Behavior {
eat(){
throw "Abstract methods cannot be used";
}
call(){
throw "Abstract methods cannot be used";
}
}
class Action {
climbTree(){
throw "Abstract methods cannot be used";
}
}
class Dog extends Behavior{
eat(food){
console.log(`狗正在吃${food}`);
}
hungry(){
console.log("汪汪汪,我饿了")
}
}
const CatMin = mix(Behavior,Action);
class Cat extends CatMin{
eat(food){
console.log(`猫正在吃${food}`);
}
hungry(){
console.log("喵喵喵,我饿了")
}
climbTree(){
console.log("爬树很开心哦~")
}
}
let dog = new Dog();
dog.eat("骨头");
dog.hungry();
let cat = new Cat();
cat.eat("鱼");
cat.hungry();
cat.climbTree();
We must be good to analyze the above code, there are two abstract classes, corresponding to different behaviors, Cat and Dog class has a common behavior, but also has its own separate Cat behavior, abstract (ie, interface) inherits its methods use interface isolation so complete their work, carry out their duties.
Demeter
What is Demeter?
Demeter: Minimum knowledge principle (Least Knowledge Principle abbreviation LKP), that is a subject should have as little understanding of other objects, do not talk to strangers. English abbreviated as: LoD (Adapted from Baidu Encyclopedia).
Demeter is the practice of the concept of decoupling between classes, weak coupling, after only weakly coupled, like reuse rate can be improved. A class should be kept to a minimum understanding of other objects. Popular terms, is a class of their dependent classes know better. Because the close relationship between the class and class, the greater the degree of coupling, when a class is changed, the influence of another class the greater
Demeter benefits?
Reducing the coupling between objects
Example:
class ISystem {
close(){
throw "Abstract methods cannot be used";
}
}
class System extends ISystem{
saveCurrentTask(){
console.log("saveCurrentTask")
}
closeService(){
console.log("closeService")
}
closeScreen(){
console.log("closeScreen")
}
closePower(){
console.log("closePower")
}
close(){
this.saveCurrentTask();
this.closeService();
this.closeScreen();
this.closePower();
}
}
class IContainer{
sendCloseCommand(){
throw "Abstract methods cannot be used";
}
}
class Container extends IContainer{
constructor(){
super()
this.system = new System();
}
sendCloseCommand(){
this.system.close();
}
}
class Person extends IContainer{
constructor(){
super();
this.container = new Container();
}
clickCloseButton(){
this.container.sendCloseCommand();
}
}
let person = new Person();
person.clickCloseButton();
Container above code as a medium, it calls the class does not know how it is to achieve internal user to trigger button, the Container notifies the computer, the computer to execute the corresponding command.
01 in combination / polymerization multiplexing principles
Polymerization (Aggregation) shows a weak 'own' relationship, reflecting object can contain A B B object is not an object but a portion A of the object.
Synthesis of (Composition) it is a strong 'owned' relations, reflecting the strict relationship between parts and the whole, the parts and the whole life cycle of the same.
Composition / polymerization: obtained by reference to other objects, dynamically defined at run time, that is to save the properties of other objects in an object, this approach requires a subject well defined interface, and this interface does not change frequently , and the object can only be accessed via the interface, we will not destroy encapsulation, so long as the same type of runtime also another object can be replaced by an object.
Synthesis of the object using the priority / polymerization will help you keep each class is encapsulated, and concentrated on a single task, so that classes and class hierarchies will remain smaller, and are less likely to grow uncontrolled monster.
Portfolio / aggregation multiplexers benefit principle?
- The new implementation is easier, since most of the functionality of the superclass by inheritance automatically enter the subclass;
- Modify or extend the inheritance comes more easily.
Example:
function mix(...mixins) {
class Mix {}
for (let mixin of mixins) {
copyProperties(Mix, mixin);
copyProperties(Mix.prototype, mixin.prototype);
}
return Mix;
}
function copyProperties(target, source) {
for (let key of Reflect.ownKeys(source)) {
if ( key !== "constructor"&& key !== "prototype"&& key !== "name") {
let desc = Object.getOwnPropertyDescriptor(source, key);
Object.defineProperty(target, key, desc);
}
}
}
class Savings {
saveMoney(){
console.log("存钱");
}
withdrawMoney(){
console.log("取钱");
}
}
class Credit {
overdraft(){
console.log("透支")
}
}
const CarMin = mix(Savings,Credit);
class UserCar extends CarMin {
constructor(num,carUserName){
super();
console.log()
this.carNum = num;
this.carUserName = carUserName;
}
getCarNum(){
return this.carNum;
}
getCarUserName(){
return this.carUserName;
}
}
let myCar = new UserCar(123456798,"Aaron");
console.log(myCar.getCarNum());
console.log(myCar.getCarUserName());
myCar.saveMoney();
myCar.withdrawMoney();
myCar.overdraft();
to sum up:
The principles embodied in the design mode dripping every design patterns that achieve these principles, to achieve code reuse, enhance the system extensibility. Therefore, design patterns are a lot of people regarded as a classic. We can properly study design patterns to slowly appreciate these design principles.