对设计模式理解

使用设计模式遵循设计原则是为了实现程序的低耦合, 高内聚,可维护,可扩展,复用性高,灵活在程序功能开发中单从实现功能的角度来看多数的功能用代码实现并不困难但是从系统的层面就需要考虑到结构扩展功能的修改等问题设计模式和原则就是站在系统的层面就考虑问题使用设计模式能帮助我们让系统更加健壮走的更远

设计原则

一个类应该只负责一个职责,对类更细粒度的划分通常情况下我们应该遵守单一职责只有在类的方法数量足够少可以在方法级别保持单一职责原则

理解: 职责单一修改时不会牵连太广,阅读时单从类名加方法名就可以明白是在做什么细粒度的划分还能增加代码的复用性

客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小接口上 (对接口的细分)

理解: 使用多个小的专门接口而不使用一个统一的接口.防止使用者面临,它不需要的接口的改变,所带来的的改变

高层模块不应该依赖底层模块二者都应该依赖其抽象抽象不应该依赖细节,细节应该依赖抽象使用接口或者抽象的目的是制定好规范,而不涉及任何具体的操作低层模块尽量要有抽象类或者接口,二者都有,稳定性更好,对象间引用时使用接口或者抽象类

理解: 面向接口编程在上层使用者与下层提供者之间建立接口/抽象类制定好具体行为规范上下不直接依赖方便替换

继承在给程序设计带来便利的同时,也带来了弊端使用继承时遵守里氏替换原则,尽量不要重写父类中的方法,在适当的情况下通过聚合,组合,依赖来解决问题

理解: 任何父类使用的地方其子类都可以替换,这样才是健康的继承关系父类中的行为是对子类共有行为的抽象如果子类需要重写父类中的方法,需要考虑父类中的行为是所有子类共有的吗?这个子类适合继承这个父类吗?

是编程中最基础,最重要的设计原则,模块和函数应该对扩展开放,对修改关闭,用抽象构建框架,用实现扩展细节

理解: 遵守其他原则就是维护开闭原则

最少知道原则,一个类对自己依赖的类知道的越少越好,只与直接的朋友通信每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类间(对象间)耦合关系,并不是要求完全没有依赖关系

理解:为了降低类之间的耦合实现功能的独立但又不可能实现完全独立劲量保持至于直接朋友 (实例的引用者,作为参数传入的对象..)依赖,如果必须建立关系劲量使用直接朋友传递

组合优于继承,尽量使用合成/聚合的方式而不使用继承找出应用中可能需要变化之处,把他们独立出来,不要和那些不需要变化的代码混在一起针对接口编程,而不是针对实现编程为了交互对象之间的松耦合设计而努力

理解: 使用类中的方法使用组合因为接口的存在替换实现更加方便使用时只需要关心使用的方法使用继承就是将父类中的所有细节暴露给子类父类发生改变时子类不得也发生改变所以组合优于继承在于灵活和低耦合