设计模式-谈谈模式和设计
模式
模式（Pattern），指事物的标准样式，百度百科上面说的，其实说白了模式就是我们现在说的套路！
模式 == 套路
模式是一种思想，说大了特别的复杂和深奥，不管怎么样模式的使用可以解决特定场景下特定的问题！
准确表达：模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。
软件模式
那么在软件中使用模式，就是软件模式（Software Pattern），用来解决软件世界中一些问题！因为是不同模式用在不同的场景之下，所以就会有很多模式出现，但是不管有出现多少准模式，分析其本质，发现还是要去遵循一些的原则，这样的模式才会更加的完美！
软件模式是在软件开发中某些可重现问题的一些有效解决方法，软件模式的基础结构主要由四部分构成，包括问题描述【待解决的问题是什么】、前提条件【在何种环境或约束条件下使用】、解法【如何解决】和效果【有哪些优缺点】。
设计模式
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。
设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素！
– 模式名称（Pattern Name）：用一两个词描述问题、解决方案和效果，用于理解该模式和方便开发使用人员理解，绝大多模式根据功能或者结构进行命名！
– 问题（problem）：何时使用，包括模式解决的问题和存在的问题！
– 解决方案（Solution）：设计模式的组成成分，以及这些组成部分之间相互关系各自的职责和协作方式等，通常使用URL类图和核心代码描述！
– 效果（Consequence）：模式的优缺点以及使用模式时应权衡的问题！
GoF设计模式只有23个，每一个模式都为某一个可重复的设计问题提供了一套解决方案。
根据用途进行分类：
创建型（Creational）- 5种：用于描述如何创建对象。
结构型（Structural）- 7种：用于描述如何实现类或对象的组合。
行为型（Behavioral）- 11种：用于描述类或对象怎么样交互以及怎么样分配职责。
根据是出来类之间关系还是对象之间关系分类:
类模式
对象模式
两种分类方式可结合使用：如单例模式：对象创建型，模板方法模式：类行为型模式。
详细类型分类如下 ：
创建型模式（Creational Pattern）
单例模式（Singleton Pattern)
简单工厂模式（Simple Factory Pattern）【不在GoF中】
工厂方法模式（Factory Method Pattern）
抽象工厂模式（Abstract Factory Pattern）
原型模式（Prototype Pattern）
建造者模式（Builder Pattern）
结构型模式（Structural Pattern）
适配器模式（Adapter Pattern）
桥接模式（Bridge Pattern）
组合模式（Composite Pattern）
装饰模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
行为型模式（Behavioral Pattern）
职责链模式（Chain of Responsesibility pattern）
命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Observer Pattern）
状态模式（State Pattern）
策略模式（Strategy pattern）
模板方法模式（Template Method Pattern）
访问者模式（Visitor Pattern）
设计原则
摘自百度百科
– 可靠性
– 健壮性
– 可修改性
– 容易理解
– 程序简便
– 可测试性
– 效率性
– 标准化原则
– 先进性
– 可扩展性
– 安全性
面向对象设计原则
在面向对象软件系统的设计中，能提供良好的可维护性，并同时提高系统的可复用和可扩展性是设计需要解决的核心问题之一。
常见的七种面向对象的设计原则：
单一职责原则（Single Responsibility Principle，SRP），一个类只负责一个功能中的相应职责
开闭原则（Open-Closed Principle,OCP）,软件实体对应的扩展开发，而对修改关闭
里斯替换原则（Liskov Substituion Principle,LSP）,所有引用基类的地方能够透明地使用其他子类对象
依赖倒置原则（Dependence Inversion Principle，DIP），抽象不应该依赖细节，细节应该依赖于抽象
接口隔离原则（Interface Segregation Principle,ISP）,使用对个专门的接口，而不使用单一的总接口
合成复用原则（Composite Reuse Principle，CRP），尽量使用对象的组合，而不是继承来达到复用的目的
迪米特法则（Law of Demeter ，LoD），一个软件实体应当尽可能少地与其他实体发生相互作用
单一职责原则
单一职责原则，说简单点就是，一个类最好只负责一个领域的职责，或者说应该有且仅有一个原因引起类的变更！
比如一个用户接口类中有：（1）连接数据库（2）查询用户信息（3）生成用户 表
那么此时这个类就不是单一职责类！
用户接口类应该只包含用户信息查询一个！
开闭原则
抽象化（接口）是开闭原则的关键！
里氏代换原则
里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
面向对象中多态的使用！~
里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
依赖倒转原则
依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
接口隔离原则
每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。
合成复用原则
复用时要尽量使用组合/聚合关系（关联关系），少用继承。
一般而言，如果两个类之间是“Has-A”的关系应使用组合或聚合，如果是“Is-A”关系可使用继承。
迪米特法则
迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。
在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！