1、设计模式和原则总述

目录

一、什么是设计模式？有什么用？

二、设计模式

 三、设计原则

---

一、什么是设计模式？有什么用？

        设计模式是一套代码设计的经验总结，使用设计模式可以提高代码的重用性、可靠性，提交代码内聚，降低代码耦合。可以通过阅读一些开源框架的源码来提升自己对设计模式的理解，明确在实战中如何使用设计模式来编写和重构代码。学习设计模式一要耐心、而要思考、三要使用。

二、设计模式

        既然设计模式是一套前辈总结的经验，那这些经验具体都有哪些呢？前辈们根据设计这段代码所实现的功能进行了分类，个人觉得如果了解一些面向对象的思想，可能更容易理解设计模式。        

        以java为例，java中有封装、类、继承、多态、方法等概念，如果我们想使用一个类，就需要创建这个类的对象，在实际开发中创建对象的代码到处都有，重复性高，耦合性高，因此针对于对象的创建，前辈们总结出了一系列创建对象的设计模式（这仅仅是我自己的理解，可能有错误，请指正），也就是第一类设计模式：创建型模式；

        类中会定义多个方法，每个方法都为完成一定的业务功能，有的一些复杂的、使用场景多变的功能可能实现和扩展起来比较困难或者不尽人意，前辈们是很聪明的，针对功能的实现也总结出了一系列设计模式，也就是第二种：行为型模式；

        使用java开发的同学在实际开发中为了解决耦合和复用问题，肯定会使用继承和多态，为了完成一个功能也肯定会有多个类或者对象进行协作，（个人理解）为了更好的实现类或者对象之间的协作和组合，前辈们总结出了一系列关于结构上的设计方法，也就是第三类设计模式：结构型模式。

        这里仅仅从大方向上介绍了设计模式分类和针对解决的场景，不具体分析，总结一下，贴一张图：

 三、设计原则

       除了代码设计的经验，还有一些设计的原则也需要知道。在平时做项目（产品）的过程中，需求变更可能是我们听过的最多概念之一，为了适应变更就需要开发人员频繁调整对应的代码，前辈们建议不要频繁修改已有的业务代码，而应该在软件设计之初就考虑后续如何进行扩展，通过扩展的方式来实现最新的业务需求，这也就是第一个原则：开闭原则，以我自己的理解就是对内封闭，对扩展开放，应尽量想办法通过扩展实现业务，而不是修改原有代码。在开发中，经常会使用继承的开发思想，想一个场景，本来通过A类就可以实现功能，现在为了迎合系统需求变更，需要通过扩展A类来实现，也就是写了一个B类来继承A类，这样在B类中扩展功能，且可以用B来替换任意使用A的场景，这也就是第二个原则：里氏替换原则，到这里可能有同学就会问了，如果B类中覆写了A类中的方法怎么办，答案是不建议覆写，因为覆写就不能完全替换了，这也是里氏替换原则的限制，子类可以对父类进行功能上的扩展，但是不能改变父类原来的功能。开发中的业务层，我们一般的开发方式是开发服务接口，在控制层通过依赖接口实现具体的业务调用，而并不是直接以来具体的业务实现类，其实这就是坚持了第三个原则：依赖倒置原则，其实我不是很清楚为什么叫“依赖倒置”，我觉得叫做“依赖抽象”或者“面向接口编程”可能更容易理解，上层去依赖抽象的接口，可以说简单一点，就是控制层中依赖服务层定义的服务接口，而不是直接去依赖实现类，这样做的好处没必要说的太复杂，举个例子，你女朋友想吃饭，她只需要和你说要吃饭就可以了，至于吃什么、怎么吃、去哪里吃你自己掂量着办，反正是要吃饭。领导让你写一个爬取数据的接口和一个清洗数据的接口，你肯定会分两节接口写，甚至会分成两个类去实现，这就是第四个原则：接口隔离原则，这个不多说，基本都会遵守，如果不遵守这个原则，基本是天天被领导骂。不知道大家之前在没有用框架管理对象时是否遇到过循环依赖的问题，这类问题很讨厌，当时为了解决这类问题，在开发时我们都尽量避免同级不同业务之间的相互调用，这在无形中也遵守了第五个原则：最小知道原则（迪米特原则），开发时尽量避免不同业务之间的代码侵染，也就是不同类之间的频繁关联，可以降低代码耦合性。最后一个原则是：单一职责原则，这个不多说，一个方法只负责一个事情，不要过分的将多个业务写到一个方法中，同样的如果不遵守这个原则，基本是天天被领导骂。总结一下六个设计原则，贴一张图：

        这些设计的模式和原则需要融会贯通，它们之间是相辅相成的，其实在平时开发中，我们已经遵守了很多设计的原则，通过使用设计模式和遵守设计原则，会使得我们的代码复用程度更高，代码间高内聚、低耦合，稳定性强、扩展性强。

        以上都是自己根据已有的经验写的一些浅薄的认识，如有纰漏，多多指教，这是在学习设计模式时留下的一些代码和感悟（tianjin-design-pattern-study: 每天学习一个设计模式，可能60天就能学通了吧）。