JavaScript 设计模式 一些笔记

设计模式

抽象类

抽象类的表现

  1. 不能被实例,只能被继承
  2. 最少有一个抽象方法(多态的具体体现)
// 汽车抽象类,当使用其实例对象的方法时会抛出错误
var Car = function() {};
Car.prototype = {
  getPrice: function() {
    return new Error("抽象方法getPrice不能调用。");
  },
  getSpeed: function() {
    return new Error("抽象方法getSpeed不能调用。");
  }
};

上面Car类其实什么都没有做,但用原型的方法还会直接报错,这一特点非常有必要,因为总会有一些子类去继承父类,这些父类经常会去定义一些必要的方法,却没有具体的实现.

一旦子类创建了一个对象,但是子类没有重写父类的方法而被调用,就会直接报错,这个对大型项目中对子类的约束是非常有必要的,代码页更加清晰

单一职责原则

...

里氏替换原则

子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法
继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障。

function Foo(){
    this.aa='sdf';
}

Foo.prototype.func1 = function(a,b){
    return a-b;
};


function Sub(){

}

Sub.prototype = new Foo();

var demo = new Sub();
console.log('100-50='+demo.func1(100,50));

//运行结果:
//100-50=50


//后来,我们需要增加一个新的功能:完成两数相加,然后再与100求和,由类B来负责。即类B需要完成两个功能:

function Sub1 (){
}

Sub1.prototype = new Foo();


Sub1.prototype.func1 = function(a,b){
    return a+b;
};

Sub1.prototype.func2 = function(a,b){
    return this.func1(a,b)+100;
};

var demo1 = new Sub1();
console.log('100-50='+demo1.func2(100,50))

//运行结果:
//100-50=250

我们发现原本运行正常的相减功能发生了错误。原因就是类Sub1在给方法起名时无意中重写了父类的方法,造成所有运行相减功能的代码全部调用了类Sub1重写后的方法,造成原本运行正常的功能出现了错误。在本例中,引用基类Foo完成的功能,换成子类Sub1之后,发生了异常。在实际编程中,我们常常会通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的几率非常大。如果非要重写父类的方法,比较通用的做法是:原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合,组合等关系代替。

里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。它包含以下4层含义:
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?
后果就是:你写的代码出问题的几率将会大大增加。

参考文档:http://blog.csdn.net/zhengzhb…

开闭原则

function Foo(){

}

Foo.prototype.getPerson = function(name){
    if(name==='tom'){
        return {
            name:"tom",
            age:'20'
        }
    }else if(name==="jack"){
        return {
            name:"tom",
            age:'20',
            sex:"boy"
        }
    }
}

console.log(new Foo().getPerson('tom'));

//这个时候 如果我要获取名为lily这个人的属性,就需要更改getPerson,这样所有调用该接口的对象都会受到影响,这个时候我们如何来重构

function Foo(){

}

Foo.prototype.personInfo = function(){};//写一个抽象方法

Foo.prototype.getPerson = function(){
    return this.personInfo();
};


var a = new Foo();
a.personInfo=function(){
    return {
        name:'lily',
        age:20,
        sex:'girl'
    }
};

console.log(a.getPerson());

状态模式

状态模式(State)允许一个对象在其内部状态改变的时候改变它的行为,对象看起来似乎修改了它的类。

状态模式的使用场景也特别明确,有如下两点:
一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。(有些对象通常会有好几个状态,在每个状态都只可以做当前状态才可以做的事情,而不能做其它状态能做的事儿)
一个操作中含有大量的分支语句,而且这些分支语句依赖于该对象的状态。状态通常为一个或多个枚举常量的表示。

一、有限状态机

状态总数(state)是有限的。

任一时刻,只处在一种状态之中。

某种条件下,会从一种状态转变(transition)到另一种状态。

// 状态机
var FSM = {
  off: {
    buttonWasPressed: function() {
      console.log("关灯");
      this.button.innerHTML = "下一次按我是开灯";   // 这是Light上的属性!!!
      this.currState = FSM.on;            // 这是Light上的属性!!!
    }
  },
  on: {
    buttonWasPressed: function() {
      console.log("开灯");
      this.button.innerHTML = "下一次按我是关灯";
      this.currState = FSM.off;
    }
  },
};
 
var Light = function() {
  this.currState = FSM.off;  // 设置当前状态
  this.button = null;
};
 
Light.prototype.init = function() {
  var button = document.createElement("button");
  self = this;
 
  button.innerHTML = "已关灯";
  this.button = document.body.appendChild(button);
  this.button.onclick = function() {
    // 请求委托给FSM状态机
    self.currState.buttonWasPressed.call(self);
  }
 
}
 
var light = new Light();
light.init();
    原文作者:设计模式
    原文地址: https://segmentfault.com/a/1190000015394367
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞