Fork me on GitHub
ookamiAntD's Blog

设计模式原则与UML类图

Preface

设计模式, 总的来说, 就是前人踩过无数的坑总结出来的软件设计经验. 在学习设计模式之前, 有必要了解它的一些规则以及建模.
UML(Unified Modeling Language)又称统一建模语言标准建模语言, 是始于1997年一个OMG(Object Management Group)标准, 它是一个支持模型化和软件系统开发的图形化语言, 为软件开发的所有阶段提供模型化和可视化支持, 包括由需求分析到规格, 到构造和配置.

Design Pattern

软件工程中, 设计模式(design pattern)是对软件设计中普遍存在(反复出现)的各种问题, 所提出的解决方案. 这个术语是由埃里希·伽玛(Erich Gamma)等人在1990年代从建筑设计领域引入到计算机科学的.

设计模式并不直接用来完成代码的编写, 而是描述在各种不同情况下, 要怎么解决问题的一种方案. 面向对象设计模式通常以类别对象)来描述其中的关系和相互作用, 但不涉及用来完成应用程序的特定类别或对象. 设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象, 避免会引起麻烦的紧耦合, 以增强软件设计面对并适应变化的能力. ——来自维基百科

六大原则.

单一职责原则

单一职责原则(Single Responsibility Principle,SRP): 就一个类而言, 应该仅有一个引起它变化的原因. 即一个类应该只负责一个功能领域中的相应职责.

单一职责原则是实现高内聚低耦合的指导方针, 它是最简单但又最难运用的原则, 需要设计人员发现类的不同职责并将其分离, 而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验.

开闭原则

开闭原则(Open-Closed Principle,OCP): 是指软件实体(类、模块、函数等等)应该可以扩展, 但是不可修改. 即软件实体应该尽量在不修改原有代码的情况下进行扩展.

为了满足开闭原则, 需要对系统进行抽象化设计, 抽象化是开闭原则的关键.

里氏替换原则

里氏替换原则(Liskov Substitution Principle,LSP): 所有引用父类的地方必须能够透明的使用子类的对象. 即子类型必须能够替换掉它们的父类型.

里氏替换原则告诉我们, 在软件中将一个基类对象替换成它的子类对象, 程序将不会产生任何错误和异常, 反过来则不成立, 如果一个软件实体使用的是一个子类对象的话, 那么它不一定能够使用基类对象. 因此在程序中尽量使用基类类型来对对象进行定义, 而在运行时再确定其子类类型, 用子类对象来替换父类对象. 同时, 里氏代换原则是实现开闭原则的重要方式之一.

依赖倒置原则

依赖倒置原则(Dependency Inversion Principle,DIP): 抽象不应该依赖细节, 细节应该依赖于抽象. 即应该针对接口编程, 而不是针对实现编程.

在大多数情况下, 我们会同时使用开闭原则、里氏代换原则和依赖倒转原则, 开闭原则是目标, 里氏代换原则是基础, 依赖倒转原则是手段.

接口隔离原则

接口隔离原则(Interface Segregation Principle,ISP): 使用专门的接口, 而不使用单一的总接口, 即客户端不应该依赖那些它不需要的接口.

根据接口隔离原则, 当一个接口太大时, 我们需要将它分割成一些更细小的接口, 使用该接口的客户端仅需知道与之相关的方法即可. 每一个接口应该承担一种相对独立的角色, 不干不该干的事, 该干的事都要干.

迪米特法则

迪米特法则(Law of Demeter,LoD): 一个软件实体应当尽可能少地与其它实体发生相互作用.

迪米特法则又称为最少知识原则LeastKnowledge Principle,LIP).
如果一个系统符合迪米特法则, 那么当其中某一个模块发生修改时, 就会尽量少地影响其他模块, 扩展会相对容易, 这是对软件实体之间通信的限制, 迪米特法则要求限制软件实体之间通信的宽度和深度. 迪米特法则可降低系统的耦合度, 使类与类之间保持松散的耦合关系.

三大类型

创建型(Creational)

  • 单例模式(Singleton): 保证一个类仅有一个实例, 并提供一个访问它的全局访问点.

  • 工厂方法(Factory Method): 定义一个创建对象的接口, 让其子类自己决定实例化哪一个工厂类, 工厂模式使其创建过程延迟到子类进行.

  • 抽象工厂(Abstract Factory): 提供一个创建一系列相关或相互依赖对象的接口, 而无需指定它们具体的类.

  • 建造者模式(Builder): 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示.

  • 原型模式(Prototype): 用原型实例指定创建对象的种类, 并且通过拷贝这些原型来创建新的对象.

结构型(Structural)

  • 适配器模式(Adapter): 适配器模式把一个类的接口变换成客户端所期待的另一种接口, 从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作.

  • 装饰模式(Decrator): 装饰模式是在不必改变原类文件和使用继承的情况下, 动态的扩展一个对象的功能. 它是通过创建一个包装对象, 也就是装饰来包裹真实的对象.

  • 代理模式(Proxy): 为其他对象提供一种代理以控制对这个对象的访问 ;

  • 外观模式(Facade): 为子系统中的一组接口提供一个一致的界面, 外观模式定义了一个高层接口, 这个接口使得这一子系统更加容易使用.

  • 桥接模式(Bridge): 将抽象部分与实现部分分离, 使它们都可以独立的变化.

  • 组合模式(Composite): 允许你将对象组合成树形结构来表现”整体-部分”层次结构. 组合能让客户以一致的方法处理个别对象以及组合对象.

  • 享元模式(Flyweight): 运用共享技术有效地支持大量细粒度的对象.

行为型(Behavioral)

  • 策略模式(Strategy): 定义一组算法, 将每个算法都封装起来, 并且使他们之间可以互换.

  • 模板方法(Template Method): 一个操作中算法的框架, 而将一些步骤延迟到子类中, 使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤.

  • 观察者模式(Observer): 定义对象间的一种一对多的依赖关系, 当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新.

  • 迭代器模式(Iterator): 提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示;

  • 职责链模式(Chain of Responsibility): 避免请求发送者与接收者耦合在一起, 让多个对象都有可能接收请求, 将这些对象连接成一条链, 并且沿着这条链传递请求, 直到有对象处理它为止.

  • 命令模式(Command): 将一个请求封装为一个对象, 从而使你可以用不同的请求对客户进行参数化, 对请求排队和记录请求日志, 以及支持可撤销的操作;

  • 备忘录模式(Memento): 在不破坏封装性的前提下, 捕获一个对象的内部状态, 并在该对象之外保存这个状态. 这样就可以将该对象恢复到原先保存的状态.

  • 状态模式(State): 允许对象在内部状态改变时改变它的行为, 对象看起来好像修改了它的类.

  • 访问者模式(Visitor): 表示一个作用于其对象结构中的各元素的操作, 它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作.

  • 中介者模式(Mediator): 用一个中介对象来封装一系列的对象交互, 中介者使各对象不需要显示地相互引用. 从而使其耦合松散, 而且可以独立地改变它们之间的交互.

  • 解释器模式(Interpreter): 给定一个语言, 定义它的文法表示, 并定义一个解释器, 这个解释器使用该标识来解释语言中的句子.

四大阶段

  1、没学之前, 什么是设计模式, 老听别人说设计模式, 感觉好高大上, 那它到底是什么鬼. 这时我们设计的代码复用性很差、难以维护.

  2、学了几个模式后, 感觉很简单, 于是到处想着要用自己学过的模式, 这样就会造成滥用. 最后感觉还不如不用.

  3、学完全部模式时, 感觉很多模式太相似了, 无法很清晰的知道各模式之间的区别、联系, 这时一脸懵逼, 脑子一团乱麻. 在使用时, 分不清要使用那种模式.

  4、模式已熟记于心, 已忘其形, 深知其意, 达到无剑胜有剑的境界, 恭喜你, 万剑归宗已练成!!!

UML

UML中有九种建模的图标, 即:
用例图类图对象图顺序图协作图状态图活动图组件图配置图

Class Diagram

在这主要学习一下类图 Class diagram .
通过显示出系统的类以及这些类之间的关系来表示系统. 类图是静态的———它们显示出什么可以产生影响但不会告诉你什么时候产生影响.

UML类的符号是一个被划分成三块的方框: 类名, 属性, 和操作. 抽象类的名字, 是斜体的. 类之间的关系是连接线.

类与类的关系

  • 泛化: 可以简单的理解为继承关系;
  • 实现: 一般是接口和实现类之间的关系;
  • 关联: 一种拥有关系, 比如老师类中有学生列表, 那么老师类和学生类就是拥有关系;
  • 聚合: 整体与部分的关系, 但是整体和部分是可以分离而独立存在的, 如汽车类和轮胎类;
  • 组合: 整体与部分的关系, 但是二者不可分离, 分离了就没有意义了, 例如, 公司类和部门类, 没有公司就没有部门;
  • 依赖: 一种使用关系, 例如创建 A 类必须要有 B 类.

StarUML

StarUML…就是一个画UML的很炫酷的工具=.=

显示interface

在staruml中, interface默认是以一个圆圈显示的(尴尬了)…, 但好在可以设置成想要的样子.

  1. 添加一个圆圈(interface)之后, 右键或选择菜单栏中的Format
  2. 选择Stereotype Display -> Label, 这样矩形就显示出来了
  3. 同样是Format, 然后把Suppress Operations取消掉, 这样操作就可以显示出来了

Gliffy

Gliffy是一个在线绘图工具, 支持Chrome插件, 非常强大.

---------------- The End ----------------
ookamiAntD wechat
欢迎您扫一扫上面的微信公众号,订阅我的博客!
谢谢大爷~

Author:ookamiAntD Yang
Link:http://yangbingdong.com/2017/design-pattern-uml-and-six-principle/
Contact:yangbingdong1994@gmail.com
本文基于 知识共享署名-相同方式共享 4.0 国际许可协议发布
转载请注明出处,谢谢!

分享到: