Android 设计模式-面向对象六大原则

 

前言

• 先说下一下为什么决定来写关于设计模式的文章，本人也是从事开发很多年了，很多人肯定都曾有过这样的想法，就是把设计模式背下来，到时候项目用到的时候就套用下，往往用到的时候早就忘了怎么写了，或许只是简单记住几个写法，现在看来这并不是真正的理解，套用不等于理解，真正理解之后会在思维里面形成一种模型，在做架构设计、封装代码时候会自然的把场景带入，去理解每一种模式的场景、优点、缺点，才能更好的运用。
• 设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

---

1.单一职责原则（SRP）

简单的说就是：一个类中应该是一组相关性很高的函数、数据的封装。两个不一样的功能不应该放在一个类中。

这个原则没有具体的划分界限，需要根据个人经验，具体业务逻辑而定。这也是优化代码的第一步。试想一下，如果所有的功能写在一个类里，那么这个类会越来越大，越来越复杂，越不易修改维护。那么根据功能，各自独立拆分出来，岂不是逻辑会清晰些。

2.开闭原则（OCP）

定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。

当软件需要变化时，我们应该尽量通过扩展的方式实现变化，而不是通过修改原有的代码来实现。因为直接的修改，可能会影响已有的正常代码。不利于出现错误时排除问题。当然实际开发中，修改原有代码与扩展代码是同时存在的。但应尽量以扩展为主。

3.里氏替换原则（LSP）

定义：所有引用父类的地方，必须能使用子类的对象。简单地说就是将父类替换为他的子类是不会出现问题，反之，未必可以。
那么里氏替换原则就是依赖于面向对象语言的继承与多态。核心原理是抽象。

这里列举一下继承的优缺点：
优点：
（1）代码重用，减少创建类的成本，每个子类都拥有父类的方法与属性。
（2）子类与父类基本相似，但与父类又有所区别。
（3）提高代码的可扩展性。
缺点：
（1）继承是侵入性的，只要继承就必须拥有父类所有的属性与方法。
（2）可能造成子类代码冗余、灵活性降低。

开闭原则和里氏替换原则是生死相依的、不离不弃的。他们都强调了抽象这一重要的特性。

4.依赖倒置原则（DIP）

定义：指代一种特定的解耦方式，使得高层次的模块不依赖于低层次的模块的实现细节的目的。他有一下几个关键点：
（1）高层模块不依赖于低层模块，应该都依赖其抽象。
（2）抽象不依赖细节。
（3）细节应依赖抽象。

解释：在Java中，抽象就是指接口或者抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的就是细节，也就是可以加上一个关键字new产生的对象。高层模块就是调用端，底层模块就是具体实现类。

依赖倒置原则在Java中的表现就是：模块间通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。

5.接口隔离原则（ISP）

定义：类间的依赖关系应该建立在最小的接口上，将庞大、臃肿的接口拆分成更小的、更具体的接口。目的是系统的解耦，从而更容易重构、更改和重新部署。

6.迪米特原则（LOD）

定义：一个类应该对自己需要耦合或者调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或依赖者只需知道他需要的方法，其他可以一概不管。这样使得系统具有更低的耦合与更好的可扩展性。

这六个原则，可以使我们在应用的后续升级、维护中更加方便、轻松应对。让我们的软件更加灵活。

总结

在我看来设计模式就像军人手中的武器，只有足够锋利才能所向披靡，光看书看文章是不够的，要自己在项目里真正的场景去使用才能更好的理解，包括在工程师成长的道路中，无论作为高级开发还是架构师都是需要对这些要理解铭记于心，才能写出更好用的代码，更稳定扩展性更强的架构，才能做到心中有剑，落叶飞花皆是兵器的境界。