设计模式(SOLID)

终于到了可以啃设计模式这一环节了。这里针对自己的理解来对SOLID五种模式进行分析。按照1,2,3,4,5的顺序对应SOLID,但1,4和2,3,5所处的部分不同,但是这些原则其实使用的时候是组合起来的。

组件原则部分

1.单一职责原则(The Single Responsibility Principle)

定义:不要存在多余一个导致类变更的原因,即,一个类只负责一项职责。
问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。
解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。
从使用角度来看:当需要修改某个类的时候原因有且只有一个。换句话说就是让一个类只做一种类型的责任,当这个类需要承担其他类型的责任的时候,就需要分解这个类。
这个原则我认为应该是理解上最容易的一个。假设有个流程代码实现如下三个功能。

{
用户输入消息代码---->用户输入消息类方法
处理消息代码---->处理消息类方法
打印消息代码---->打印消息类方法
}

其实,从上面的框架就可以看出来,这段代码实现三个功能,单一职责原则就是,我们让每项功能都独立实现,使用时调用相应的类方法即可,而不需要每次对代码进行上下文修改。
该方法的优点:
1.可以降低类的复杂度,一个类负责一项职责,其逻辑会比负责多项职责简单。
2.提高类的可读性,提高系统的可维护性。
3.变更引起的风险降低,变更是必然的,如果SPR原则遵守的很好,当修改一个功能的时候,可以显著降低对其他功能的影响。
无论面向对象编程还是面向过程编程,只要是模块化的程序设计,都需要遵守这一原则。
缺点:
当项目很大的时候, 可能会有很多功能,会有爆炸式的类,这种时候就需要考虑如何用文件夹设计你的工程项目,使其易读。

4.接口分离原则(The Interface Segregation Principle)

定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。
解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
从使用角度来看: 不能强迫用户去依赖那些他们不使用的接口。换句话说,使用多个专门的接口比使用单一的总结口要好。

interface IAA:basicinterface, additional1interface
{
base functions
additional1 functions
}
interface IBB:basicinterface, additional2interface
{
base functions
additional2 functions
}
class AA: IAA
{
***
}
class BB:IBB
{
***
}

从上面的接口可以看出来,我们有两个接口AA,BB,这两个接口分别都继承同一个公共接口和不同的功能接口,我们可以以员工为实体例子来思考,不同的员工都有基本信息,但是根据职位的不同,员工的可以获得的职权功能也是不同的,不同部门的权限也是不同的。我们不应该把所有功能都放在一个接口里让类去实现,而是要把接口单一化,可以继承多个接口,但不要继承一个庞大但有很多无用功能的接口。
注意:使用ISP规则的时候:
1.接口设计一定要谨慎,不能过小或者过大,过小的接口会让文件十分琐碎,但是过大的接口则会使修改时的依赖增大
2:为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。
3.对外交互尽量少,用最小的几口完成最多的事,要加强内聚。

联系原则部分

2.开闭原则(The Interface Segregation Principle)

定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。
解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
从使用角度:软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。这个原则是诸多面向对象编程中最抽象、最难理解的一个。
ISP原则,其实就是要我们不要直接继承类,而是继承接口来实现,我们不改变接口,只改变实现方式或增加接口。

class model--->提取成接口
{
string name,
string address,
这里要新添加一个方法。-->为这新的方法在接口中书写默认值,然后赋值到符合这个属性的不同的类。
}

我们在基础类里面对这个方法需要的属性也是需要增加的。但是在实现的时候,我们可以根据功能性来进行分离,还是以公司员工举例,原来只有基本信息功能,我们现在要添加经理,还是CEO的功能,我们需要在基础员工信息里面添加这两个属性(默认为false),然后在创建员工档案的时候,分为普通员工,经理,CEO这些不同的员工来进行创建。但这三者在基础的接口是一样的,但是在继承接口实现不同类来创建不同的账号权限。

3.里氏替换原则(The Liskov Substitution Principle)

定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。
定义2:所有引用基类的地方必须能透明地使用其子类的对象。
问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。
解决方案:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。
从使用角度:当子类的实例应该能够替换任何超类的实例时,它们之间才具有is-a关系
个人感觉,这个模式出故障可能的一个问题在于定义接口的时候,分工不是那么明确,可能把可以分离的功能放在一起,当定义实类或子类的时候,有些定义是需要那些功能,有些是不需要的,如果主程序原来是需要的,用不需要功能的子类替换的时候就会出现问题。这个时候,解决方法应该还是要把接口分开。当然可能还有其他情况,这里的规则就是子类可以替换父类而使程序没有错误。

5.依赖倒置原则(Dependency Inversion Principle)

定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。
解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。

static void Main(string[] args){
Person owner = new Person{
FirstName = "Tia",
LastName = "Bob",
PhoneNumber="13242"
}
Chore chore = new Chore{
ChoreName = "Take the task",
Owner = owner
}
chore.Performance(2);//进行工作时间累计
chore.CompleteChore();//提示工作完成
}

因为高层不应该直接依赖低层代码,我们应该看到的代码是功能会被执行,而不是怎么执行。所以,我们把高层代码里可以看到的new **都放到一起,且用相应继承的接口类型来定义返回值。这里只是展示了main代码里的new,其他高层代码也需要这么处理。

public static class Factory
{
   public static IPerson Create Person()
  {
    return new Person();
  }
  public static IChore CreateChore()
  {
    return new Chore();
  }
}
则之前那篇代码可以改成
{
IPerson owner = Factory.CreatePerson();
owner.FirstName="";
owner.LastName="";
owner.PhoneNumer="";
IChore chore = new Factory.CreateChore();
chore.ChoreName="";
chore.Owner = owner;
....
}

总结:

设计模式的出发点是为了让我们的代码变得更鲁棒,更能适应变更而不会因为变更带来很大的工作量。
规划好模块的属性和方法,合理的设计接口,类实现通过继承相应的接口来实现。接口定义需要的基本功能,我们对接口进行拼装可以生成更复杂的专门接口。最后类是通过接口来进行实现的。
设计是为了更好的合作和维护。但最重要的不是代码,是人,是团队,坏代码可以通过学习实践,几天改写成好代码,但是坏团队不会几天变成好团队。

你可能感兴趣的:(设计模式(SOLID))