欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。
欢迎跳转到本文的原文链接:https://honeypps.com/design_pattern/quick_start/
最近在整理设计模式这个系列,这里做一下全局的概括。本系列的文章对于初识设计模式的朋友也许不太适应,对于那些了解过或者使用过设计模式的人比较适应,本系列的文章对设计模式的关键点做了一个终结性的陈述,也列举了相关例子方便理解和记忆,但是并没有循序渐进的讲解。譬如,在适配器模式中,博主阐述了适配器的定义、类图、案例等,但是并没有阐述类似“比如你买了一个港版的iphone6s,但是大陆的插座不并适合,需要一个转接口,这个转接口就是适配器”这样的语句来更形象的讲解相关内容。
虽然关于设计模式的文章铺天盖地,但是博主还是想自己整理一下,符合自己思路的设计模式。最近看到一句话,非常有感触,大概是这样说的:坚持做自己懒得做却正确的事,你就能得到别人想得到缺得不到的东西。
面向对象的设计原则
熟记面向对象的设计原则可以更好的理解设计模式,对于面向对象的设计原则,各个版本的说法不一,有说五种的,有说六种的,但是基本就是下面七种原则的组合,这里全部罗列出来,加深一下印象(非斜体的在每个版本中都有)。
- SRP:单一职责原则,一个类应该仅有一个引起它变化的原因。Single Responsibility Principle
- OCP:开闭原则,讲的是设计要对扩展有好的支持,而对修改要严格限制。Open Close Principle
- LSP:里氏替换原则,子类必须能够替换基类,否则不应当设计为其子类。Liskov Substitution Principle
- DIP:依赖倒换原则,设计要依赖于抽象而不是具体化。Dependence Inversion Principle
- ISP:将打的接口打散成多个小接口。 Interface Segregation Principle
- LoD:迪米特法则,一个对象应当尽可能少的去了解其它对象。也就是一个关于如何松耦合的法则。Law of Demeter,也称为最少只是原则LKP Least Knowledge Principle
- CARP:优先使用复合/聚合,而不是继承。Composition Aggregation Principle
设计模式的分类
设计模式一共可以分为23种,3大类:
创建型
- Factory Method(工厂方法)http://blog.csdn.net/u013256816/article/details/50975438
- Abstract Factory(抽象工厂)http://blog.csdn.net/u013256816/article/details/50975438
- Builder(建造者)http://blog.csdn.net/u013256816/article/details/50978024
- Prototype(原型)http://blog.csdn.net/u013256816/article/details/50981322
- Singleton(单例)http://blog.csdn.net/u013256816/article/details/50966882
结构型 - Adapter Class/Object(适配器)http://blog.csdn.net/u013256816/article/details/51000290
- Bridge(桥接)http://blog.csdn.net/u013256816/article/details/51000327
- Composite(组合)http://blog.csdn.net/u013256816/article/details/51009417
- Decorator(装饰)http://blog.csdn.net/u013256816/article/details/51009449
- Facade(外观)http://blog.csdn.net/u013256816/article/details/51009480
- Flyweight(享元)http://blog.csdn.net/u013256816/article/details/51009522
- Proxy(代理)http://blog.csdn.net/u013256816/article/details/51009592
行为型 - Interpreter(解释器)http://blog.csdn.net/u013256816/article/details/51058049
- Template Method(模板方法)http://blog.csdn.net/u013256816/article/details/51018676
- Chain of Responsibility(责任链)http://blog.csdn.net/u013256816/article/details/51058075
- Command(命令)http://blog.csdn.net/u013256816/article/details/51058106
- Iterator(迭代器)http://blog.csdn.net/u013256816/article/details/51058234
- Mediator(中介者)http://blog.csdn.net/u013256816/article/details/51058254
- Memento(备忘录)http://blog.csdn.net/u013256816/article/details/51244961
- Observer(观察者)http://blog.csdn.net/u013256816/article/details/51245002
- State(状态)http://blog.csdn.net/u013256816/article/details/51245024
- Strategy(策略)http://blog.csdn.net/u013256816/article/details/51245046
- Visitor(访问者)http://blog.csdn.net/u013256816/article/details/51245073
各个模式之间的对比 http://blog.csdn.net/u013256816/article/details/51245096
类图
熟练的掌握类图能够方便理解和记忆设计模式。这里沿用了资料1中所陈述的内容。
常见的有以下几种关系:泛化(Generalization)、实现(Realization)、关联(Association)、聚合(Aggregation)、组合(Composition)、依赖(Dependency)
- 泛化:是指一种继承(extends)关系。在UML类图中,用空心三角形+实线来表示,箭头指向父类。
- 实现:一般来讲实现(implements)是针对类与接口之间的关系而言的。在UML类图中,用空心三角形+虚线来表示。
- 关联:是一种拥有的关系,它使用一个类知道另一个类的属性和方法。如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头,箭头指向被拥有者。(代码体现:成员变量)
- 聚合:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车依然存在。聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。在UML类图中,用带空心菱形的实心线表示,菱形指向整体。(代码体现:成员变量)
- 组合:是整体和部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。在UML类图中,用带实心的菱形的实线表示,菱形指向整体。(代码体现:成员变量)
- 依赖:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖。在UML类图中,用带箭头的虚线表示,指向被使用者。(代码体现:局部变量、方法的参数或者对静态方法的调用)
各个关系的强弱顺序:泛化=实现>组合>聚合>关联>依赖。
参考资料
欢迎跳转到本文的原文链接:https://honeypps.com/design_pattern/quick_start/
欢迎支持笔者新作:《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客。