Android设计模式解析（一）

设计模式：代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

随着开发的经验积累，简单的搬砖已经不满足自身的需求了，往往总会想该如何去提升自己，总感觉做的东西达不到满意，但是该怎么做却又不知道，那不如先从思索一下设计模式。一呢可以让自己提升点知识，二呢在这个互联网低潮期增加点资本。

设计模式大家在日常开发中会经常用到，可能会有许多人并没有注意到，现在就来一点点的整理下。

原则

设计模式遵循面向对象的6大原则

单一职责原则（SRP）

就一个类而言，只能又一个引起他变化的原因。

简单来说就是一个类的功能和职责应该是单一的，是一组相关性很高的功能的封装

• 要尽量清除职责的划分，单一职责的划分会根据每个人理解经验会有不同
• 超出自己职责范围的功能交给其他的类来处理；
• 将一个很复杂的功能封装在一个类中是不好的，区分封装到一组类中（虽然感觉类多了，会繁琐，其实不然，都在一个类后期修改真的很痛苦）

开闭原则（OCP）

软件中的对象（类、模块、函数等）应该是对拓展开放的，但是对修改关闭

在对软件的升级和维护等过程中，需要对软件的原有的代码进行修改的话，就有可能会将错误引入原本已经通过测试的旧代码中，破环原有的系统。因此当软件需要变化时，我们应该尽量通过拓展的方式来实现变化，而不是通过修改已有的代码来实现。
当然，在现实的开发中，只通过继承的方式来升级、维护原有的系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、拓展代码往往是同时存在的。

里氏替换原则（LSP）——构建拓展性更好的系统

所有引入基类（父类）的地方，必须能透明的使用子类的对象

里氏替换原则就是依赖于继承、多态两大特征。只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或者误解，使用者可能根本就不需要知道是父类还是子类。其实最终总结就是两个字：抽象

里氏替换原则的核心原理就是抽象，抽象又依赖于继承这个特性，在面向对象中，继承的优缺点都相当明显

• 优点
  
  • 代码的重用，减少创建类的成本，每个子类都用父类的方法和属性；
  • 子类于父类基本相似，但是又与父类有所区别
  • 提高了代码的可拓展性
• 缺点
  
  • 继承是侵入性的，只要继承就必须用于父类的所有属性和方法；
  • 可能造成子类代码的冗余、灵活性降低，因为子类必须有父类的属性和方法；

依赖倒置原则（DIP）—–让代码用于变化的能力

指代了一种特定的解耦形式，使得高层次的模块不依赖低层级的模块的实现细节的目的，依赖模块被颠倒了。

依赖倒置原则有一下几个关键点

1. 高层模块不应该依赖于低层级模块，两者应该依赖其抽象
2. 抽象不应该依赖细节；
3. 细节应该依赖抽象。

高层模块就是调用端，低层模块就是具体的实现类。依赖倒置原则在Java语言中的表现就是：模块的依赖通过抽象发生，实现类之间不发生不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的。

一句话概括：依赖抽象，而不依赖具体实现。

接口隔离原色（ISP）——系统有更高的灵活性

客户端不应该依赖不需要的接口（类间的依赖关系应该建在最小的接口上）

接口隔离原则将非常庞大、臃肿的接口拆分成更小的、更具体的接口，这样客户将会只需知道他们感兴趣的方法。

接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。

迪米特原则（LOD）——更好的拓展性

迪米特原则，也称做少只是原则。一个对象应该对其他对象有最少的了解

一个类应该对自己需要耦合或者调用的类知道的最少，类的内部知道如何与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可以一概不管。