单一职责原则
就一个类而言,应该仅有一个可以引起他变化的原因。
如果一个类承担的职责太多,就等于把这些职责都耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏
如果能想到多于一个的动机去改变一个类,那么这个类就具备多于一个的职责,就应该考虑类的职责分离
开放-封闭原则
是说软件实体应该可以扩展但是不能修改
该原则是为了:设计在面对需求的改变时却可以保持相对的稳定,从而可以使系统在第一个版本之后不断推出新的版本,不至于在新的需求到来后,要把整个系统推倒重来
无论模块是多么封闭,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化
面对需求,对程序的改动是通过新增代码来实现的,而不是更改现有代码
开发人员应仅对程序中呈现出频繁变化的那部分做出抽象,然而,对于应用程序中每个部分都刻意的进行抽象同样不是好主意,拒绝不成熟的抽象和抽象本身一样重要
依赖倒转原则
抽象不应该依赖细节,细节应该依赖于抽象(针对接口编程,不要对(具体)实现编程)
A、高层模块不应该依赖低层模块。两个都应该依赖抽象
B、抽象不应该依赖细节。细节应该依赖抽象
里氏代换原则:
子类必须能够替换掉它的父类型
(1)子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里氏代换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义,如果一个方法只存在子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。
(2) 我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。
装饰模式
动态的给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更灵活
Component是定义一个对象接口,可以给这些对象动态的添加职责。
ConcretComponet是定义一个具体的对象,也可以给这些对象的添加一些职责
Decorate,装饰抽象类,继承了Compont,从外类来扩展Component的功能,但对于Component类来说,是无需知道Decorate类的存在的
ConcretDecorate是具体的装饰对象,起到给Component添加职责的功能
基础代码:
abstractclass Component
{
public abstract void Operation();
};
classConcretComponent :Component
{
public override void Operation()
{
Console.WriteLine("具体对象的操作");
}
};
abstractclass Decorate :Component
{
Component component;
public SetComponent(Componentcomponent)
{
this.component = component;
}
public override void Operation()
{
if (component != null)
component.Operation();
}
};
classConcretDecorateA :Decorate
{
private string addedState;
public override void Operation() //这里首先运行原Component的Operation,再执行本类的功能,比如addedState,相当于对原Component进行了装饰
{
base.Operation();
addedState = "NewState";
Conlsole.WriteLine("一些装饰的操作");
}
};
classConcretDecorateB :Decorate
{
public override void Operation() //这里同上面的DecorateA一样,在执行完Component的Operation后可以继续执行装饰操作
{
base.Operation();
AddBehavior();
Colsole.WriteLine("另一些装饰操作");
}
private void AddBehavior()
{
//...
}
};
voidmain()
{
ConcretComponent cc = newConcretComponent();
ConcretDecorateA d1 = newConcretDecorateA();
ConcretDecorateB d2 = newConcretDecorateB();
//从这里,我们就可看出装饰模式的突出之处
//首先用ConcretComponent实例化对象cc,然后用ConcretDecorateA的实例化对象d1来装饰cc,最后用ConcretDecorateB的实例化对象d2来装饰d1
d1.SetComponent(cc);
d2.SetComponent(d1);
d2.Operation();
}
比如给美女换衣服的例子套用装饰模式:
class Person
{
public Person()
{ }
private string name;
public Person(string name)
{
this.name = name;
}
public virtual void Show()
{
Console.WriteLine("装扮的{0}", name);
}
}
class Finery : Person
{
protected Person component;
//打扮
public void Decorate(Personcomponent)
{
this.component =component;
}
public override void Show()
{
if (component !=null)
{
component.Show();
}
}
}
class TShirts : Finery
{
public override void Show()
{
Console.Write("大T恤 ");
base.Show();
}
}
class BigTrouser : Finery
{
public override void Show()
{
Console.Write("垮裤 ");
base.Show();
}
}
class Sneakers : Finery
{
public override void Show()
{
Console.Write("破球鞋 ");
base.Show();
}
}
class Suit : Finery
{
public override void Show()
{
Console.Write("西装 ");
base.Show();
}
}
class Tie : Finery
{
public override void Show()
{
Console.Write("领带 ");
base.Show();
}
}
class LeatherShoes : Finery
{
public override void Show()
{
Console.Write("皮鞋 ");
base.Show();
}
}
}
staticvoid Main(string[] args)
{
Person xc = newPerson("Ben");
Console.WriteLine("\n第一种装扮:");
Sneakers pqx = new Sneakers();
BigTrouser kk = new BigTrouser();
TShirts dtx = new TShirts();
pqx.Decorate(xc);
kk.Decorate(pqx);
dtx.Decorate(kk);
dtx.Show();
Console.WriteLine("\n第二种装扮:");
LeatherShoes px = new LeatherShoes();
Tie ld = new Tie();
Suit xz = new Suit();
px.Decorate(xc);
ld.Decorate(px);
xz.Decorate(ld);
xz.Show();
}
总结:
装饰模式是为已有功能动态添加更多功能的一种方式
何时使用?
起初的设计中,当系统需要新的功能的时候,是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为,但是他们在主类中加入了新的字段,新的方法、逻辑,从而增加主类的复杂度,而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。
而装饰模式提供了很好的解决方案,他把每个要装饰的功能放在单独的类中,并让这个类包装它所要装饰的对象。
因此,当需要执行特殊行为时,客户代码就可以在运行时根据需要有选择的、按顺序的使用装饰功能包装对象
优点:
把类中的装饰功能从类中搬移出去,可以简化原来的类
有效的把类的核心职责和装饰功能区分开了,而且可以去除相关类中重复的装饰逻辑