wordpress网站反应慢,外包网站开发价格,网站模板上传,网络运营培训班多少钱0.设计模式的分类 GoF提出的设计模式总共有23种#xff0c;根据目的准则分类分为三大类#xff1a;
创建型模式#xff0c;共五种#xff1a;单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。 结构型模式#xff0c;共七种#xff1a;适配器模式、装饰模式…0.设计模式的分类 GoF提出的设计模式总共有23种根据目的准则分类分为三大类
创建型模式共五种单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。 结构型模式共七种适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式共十一种策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 另外随着设计模式的发展也涌现出很多新的设计模式它们分别是规格模式、对象池模式、雇工模式、黑板模式和空对象模式等。 1. 单一职责原则(SRP) 定义就一个类而言应该仅有一个引起它变化的原因。 从这句定义我们很难理解它的含义通俗讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多就等于把这些职责耦合在一起一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计当变化发生时设计会遭受到破坏。 比如我经常看到一些Android开发在Activity中写Bean文件网络数据处理如果有列表的话Adapter 也写在Activity中问他们为什么除了好找也没啥理由了把他们拆分到其他类岂不是更好找如果Activity过于臃肿行数过多显然不是好事如果我们要修改Bean文件网络处理和Adapter都需要上这个Activity来修改就会导致引起这个Activity变化的原因太多我们在版本维护时也会比较头疼。也就严重违背了定义“就一个类而言应该仅有一个引起它变化的原因”。 当然如果想争论的话这个模式是可以引起很多争论的但请记住一点你写代码不只是为了你也是为了其他人。
2. 开放封闭原则(ASD) 定义类、模块、函数等等等应该是可以拓展的但是不可修改。 开放封闭有两个含义一个是对于拓展是开放的另一个是对于修改是封闭的。对于开发来说需求肯定是要变化的但是新需求一来我们就要把类重新改一遍这显然是令人头疼的所以我们设计程序时面对需求的改变要尽可能的保证相对的稳定尽量用新代码实现拓展来修改需求而不是通过修改原有的代码来实现。 假设我们要实现一个列表一开始只有查询的功能如果产品又要增加添加功能过几天又要增加删除功能大多数人的做法是写个方法然后通过传入不同的值来控制方法来实现不同的功能但是如果又要新增功能我们还得修改我们的方法。用开发封闭原则解决就是增加一个抽象的功能类让增加和删除和查询的作为这个抽象功能类的子类这样如果我们再添加功能你会发现我们不需要修改原有的类只需要添加一个功能类的子类实现功能类的方法就可以了。
3.里氏替换原则(LSP) 定义所有引用基类父类的地方必须能透明地使用其子类的对象 里氏代换原则告诉我们在软件中将一个基类对象替换成它的子类对象程序将不会产生任何错误和异常反过来则不成立如果一个软件实体使用的是一个子类对象的话那么它不一定能够使用基类对象。 里氏代换原则是实现开闭原则的重要方式之一由于使用基类对象的地方都可以使用子类对象因此在程序中尽量使用基类类型来对对象进行定义而在运行时再确定其子类类型用子类对象来替换父类对象。 在使用里氏代换原则时需要注意如下几个问题
子类的所有方法必须在父类中声明或子类必须实现父类中声明的所有方法。根据里氏代换原则为了保证系统的扩展性在程序中通常使用父类来进行定义如果一个方法只存在子类中在父类中不提供相应的声明则无法在以父类定义的对象中使用该方法。 我们在运用里氏代换原则时尽量把父类设计为抽象类或者接口让子类继承父类或实现父接口并实现在父类中声明的方法运行时子类实例替换父类实例我们可以很方便地扩展系统的功能同时无须修改原有子类的代码增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。 Java语言中在编译阶段Java编译器会检查一个程序是否符合里氏代换原则这是一个与实现无关的、纯语法意义上的检查但Java编译器的检查是有局限的。 4.依赖倒置原则(DIP) 定义高层模块不应该依赖低层模块两个都应该依赖于抽象。抽象不应该依赖于细节细节应该依赖于抽象。 在Java中抽象就是指接口或者抽象类两者都是不能直接被实例化的细节就是实现类实现接口或者继承抽象类而产生的就是细节也就是可以加上一个关键字new产生的对象。高层模块就是调用端低层模块就是具体实现类。 依赖倒置原则在Java中的表现就是模块间通过抽象发生实现类之间不发生直接依赖关系其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节那么就会直接耦合那么当修改时就会同时修改依赖者代码这样限制了可扩展性。
5.迪米特原则(LOD) 定义一个软件实体应当尽可能少地与其他实体发生相互作用。 也称为最少知识原则。如果一个系统符合迪米特法则那么当其中某一个模块发生修改时就会尽量少地影响其他模块扩展会相对容易这是对软件实体之间通信的限制迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度使类与类之间保持松散的耦合关系。 迪米特法则要求我们在设计系统时应该尽量减少对象之间的交互如果两个对象之间不必彼此直接通信那么这两个对象就不应当发生任何直接的相互作用如果其中的一个对象需要调用另一个对象的某一个方法的话可以通过第三者转发这个调用。简言之就是通过引入一个合理的第三者来降低现有对象之间的耦合度。 在将迪米特法则运用到系统设计中时要注意下面的几点在类的划分上应当尽量创建松耦合的类类之间的耦合度越低就越有利于复用一个处在松耦合中的类一旦被修改不会对关联的类造成太大波及在类的结构设计上每一个类都应当尽量降低其成员变量和成员函数的访问权限在类的设计上只要有可能一个类型应当设计成不变类在对其他类的引用上一个对象对其他对象的引用应当降到最低。
6.接口隔离原则(ISP) 定义一个类对另一个类的依赖应该建立在最小的接口上。 建立单一接口不要建立庞大臃肿的接口尽量细化接口接口中的方法尽量少。也就是说我们要为各个类建立专用的接口而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。 采用接口隔离原则对接口进行约束时要注意以下几点
接口尽量小但是要有限度。对接口进行细化可以提高程序设计灵活性但是如果过小则会造成接口数量过多使设计复杂化。所以一定要适度。 为依赖接口的类定制服务只暴露给调用的类它需要的方法它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务才能建立最小的依赖关系。 提高内聚减少对外交互。使接口用最少的方法去完成最多的事情。 这六个原则可以使我们在应用的迭代维护中更加方便、轻松的应对让我们的软件更加灵活。在后续的文章中我会给大家介绍其他的设计模式。
