C#设计模式原则
2021-07-03 01:36
标签:良好的 抽象 虚方法 机制 好的 单一职责 耦合 编程 一个 原则的诞生: 注:如果Method()被实现为虚方法,并且在子类中可以被重写,则传入DoSomeThing的参数既可以是父类类型也可以是子类类型,子类完全可以代替父类在此调用自己的方法 C#设计模式原则 标签:良好的 抽象 虚方法 机制 好的 单一职责 耦合 编程 一个 原文地址:https://www.cnblogs.com/bruseekaka/p/9906761.html
面向对象:封装、继承、多态三大支柱蕴含了用抽象来封装变化,降低耦合,实现复用的精髓;
封装:隐藏内部的实现,保护内部信息;
继承:实现复用,归纳共性;
多态:改写对象行为,实现更高级别的继承
要实现这些目的,就必须遵守一些原则:封装变化、对接口编程、少继承多聚合
实现系统的可扩展、可复用、灵活性好、维护性好
一、开-闭原则(ocp)
1.核心思想:软件应该是可扩展的,而不可修改的
2.对扩展开发:有新的需求或变化时,可以对现有代码进行扩展,以适应新情况
3.对修改关闭:类一旦设计完成,就可以单独完成自己的工作,而不要再对类进行任何修改。
4.实现方式:抽象,多态,继承,接口
二、单一职责原则(srp)
1.目的:如果你有多个原因去改变一个类,那么应该把这些引起变化的原因分离开,把这个类分成多个类,每个类只负责处理一种改变。当你做出某种改变时,只需要修改负责处理该改变的类
2.单一职责原则
.一个类应该只受一种变化的影响
.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这些个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。
.优点:消除耦合,减小因需求变化引起代码僵化性臭味
.使用srp注意点:
(1).一个合理的类,应该仅有一个引起它变化的原因,即单一职责;
(2).在没有变化征兆的情况下应用srp或其他原则是不明智的;
(3).在需求实际发生变化时就应该应用srp等原则来重构代码;
(4).使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码;
(5).如果测试不能迫使职责分离,僵化性和脆弱性的臭味会变得很强烈,那就应该用facade或proxy模式对代码重构
三、接口隔离原则(ISP)
1.目的:当我们设计应用程序的时候,如果一个模块包含多个子模块,那么我们应该小心对该模块做出抽象。
2.接口隔离原则:表明客户端不应该被强迫实现一些他们不会使用的接口,应该把胖接口中的方法分组,然后用多个接口代替它,每个接口服务于一个子模块。
四、里氏代换原则(LSP)
1.核心思想:子类必须能够替换基类
2.在一个软件系统中,子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作
3.目的:当我们设计程序模块时,我们会创建一些类层次结构,然后我们通过扩展一些类来创建他们的子类,我们必须确保基类的引用可以被子类替换而不影响模块的功能,否则当我们在已有程序模块中使用他们时将会产生不可预料的结果
示例: public class Father
{
public string type;
public Father()
{
type = "father";
}
///
总结:Liskov替换原则是关于继承机制的设计原则,违反了Liskov替换原则必然导致违反开闭原则;Liskov替换原则能够保证系统具有良好的扩展性,同时实现基于多态的抽象机制,能够减少代码冗余,避免运行期间的类型判断。子类必须满足基类和客户端对其行为的约定,客户端对行为的期望在子类和基类中必须保持一致。
五、依赖倒转原则(DIP)
(1)、目的:在一个应用程序中,我们有一些实现了基础的,主要的操作的底层类和一些封装了复杂逻辑的上层类。实现这种结构的很自然的方式就是,先编写底层类,完成后再编写复杂的上层类。因为上层类是由其他东西定义的,所以这看起来是一种很合理的方式。但是这不是一个灵活的设计,如果我们需要替换一个底层类时会发生什么?
(2)、依赖:所谓依赖,举例:一个类Person,另一个类Car,如果Person的某个方法比如说drive,需要引用Car,则称Person类依赖于Car类
六、组合优先于继承
(1)继承:它可以使用现有类的所有功能,并在无需重新编写原来的类的情况下对这些功能进行扩展
(2)组合:通过创建一个由其他对象组合的对象来获得新功能的重用方法,新功能的获得是通过调用组合对象的功能实现的,有时又叫聚合
(3)继承与组合:继承与子类之间是“ls-a”的关系;组合与其它类之间是“Has-a”的关系