说明:设计模式(Design Pattern)对于软件开发,简单来说,就是软件开发的套路,固定模板。在学习设计模式之前,需要首先学习UML(Unified Modeling Language,统一建模语言)和面向对象设计的七大原则。
UML
设计模式在代码开发之前,先需要使用设计图的方式表现出来,UML是生产设计图的语言,也就是模型语言。UML的结构有视图(View)、图(Diagram)、模型元素(Model Element)、通用机制(General Mechanism),这里不做过深的介绍,只介绍类图和类之间的关系。
类图(Class Diagram)
结构
一般来说,一个类由三个部分组成:类名、属性和方法。如下这个类图:
- 类名:Teacher;
- 属性:name(String)、age(int,默认值是0)、gender(String);
- 方法:setAge(int age)、getName();
其中,属性和方法前面的符号,分别表示可见性:公有(public)、私有(private)、受保护(protected)分别用“+”、“-”、“#”来表示,在Java中,还有一种包内可见性(package),使用“*”来表示。
对于属性,在属性类型后面加 “= xx”,表示此属性设置默认值为“xx”,表示方式如下:
可见性 名称:类型 [= 默认值]
对于方法,表示方式如下:
可见性 名称([参数列表])[:返回类型]
以上方括号中的部分,表示可有可无;
如果该类是一个接口,类图表示如下:
其他内容不变,类名上面加两个尖括号包裹的interface,也有在类名左上角使用一个类似圆形取卡针标志来表示的,如下:
类之间关系
类与类之间的关系,分为以下几种:
关联关系
关联,指类与类之间存在联系,可分为双向关联、单向关联、自关联、多重性关联、聚合和组合,如下:
如下,表示一个按钮(Button)只能属于一个表单(Form),是一对一的关系,而一个表单,可以有0个或多个按钮;
常见的多重性关系有:1…1(一对一)、0…* (0对多) 、1…*(1对多)、0…1(0对一)、m…n(多对多);
例如,汽车(Car)与发动机(Engine),发动机是汽车的组成部分,可以独立于汽车存在,并不依赖于汽车;
例如,头(Head)与眼睛(Eye),眼睛是头的组成部分,但是眼睛不能单独出来,头没有了眼睛也就没有了;
依赖关系;
例如,驾驶员(Driver)与车(Car)的关系,驾驶员依赖于车,没有车就无法使用驾驶方法;
泛化关系;
泛化关系,就是继承关系,如下,学生类(Student)和教师类(Teacher)继承于人类(Person);
实现关系;
实现关系,顾名思义,如下,船(Ship)与车(Car)实现于交通工具接口(Vehicle),并实现其移动方法(move);
其他
实际上,UML的图远不止这些,还有用例图(Use Case Diagram)、对象图(Object Diagram)、包图(Package Diagram)等加上类图共13个,但是类图用的最多。
在我手边的《设计模式》(第二版,清华大学出版社,第5页,刘伟主编)中,作者引用了Martin Fowler著作中的一段话,“If someone were to come up to you in a dark alley and say, ‘Psst, wanna see a UML diagram?’ that diagram would probably be a class diagram.The majority of UML diagrams I see are class diagrams.”(“如果有人在黑暗的小巷中向你走来并对你说:'嘿,想不想看一张UML图?'那么这张图很有可能就是一张类图,我所见过的大部分的UML图都是类图”)
面向对象设计原则
面相对象设计原则,指在程序设计时遵循的规范,有以下七个:
单一职责原则(Single Responsibility Principle,SRP)
单一职责原则定义:一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。
简单来说,就是一个类,应该只干一件事。例如在没有三层架构前,一个请求,从接收、分析、处理,都在一个类里完成,无论这个请求的哪一个环节发生了改变都需要修改代码,可维护性差,代码耦合高。
开闭原则(Open-Closed Principle,OCP)
开闭原则定义:一个软件实体应当对扩展开发,对修改关闭。
就是说,后面如果需要新增需求,可以在不修改源码的基础上,对系统扩展。举个例子,一个管理系统的界面,有许多的记录,许多筛选项,最开始记录的字段少,筛选项也少,后面字段越来越多,需要新增一些筛选条件。
不符合开闭原则的做法:对DTO对象不断地新增筛选项,name(姓名)、age(年龄)、createTime(创建时间)……;
符合开闭原则的做法:在DTO对象里定义一个Map对象conditions,用于接收前端传递的条件参数。这样无论后面新增多少个筛选条件,实体类都不需要修改,只需要在Mapper.xml里面新增筛选字段(conditions.字段名)的查询条件即可;
private Map<String, String> conditions;
里氏代换原则(Liskov Substitution Principle,LSP)
里氏代换原则可以通俗表述为:在软件中如果能够使用基类(父类)对象(的地方),那么一定能够使用其子类对象。
依赖倒转原则(Dependency Inversion Principle,DIP)
依赖倒转原则定义:高层模块不应该依赖底层模块,他们都应该依赖抽象。抽象不应该依赖细节,细节应该依赖于抽象。
接口隔离原则(Interface Segregation Principle,ISP)
接口隔离原则定义:客户端不应该依赖那些它不需要的接口。
就是说,对于接口应该尽可能细化,而不是把一堆接口放到到一个大接口里面。如接口A表示飞行,接口B表示跳跃,接口C表示鸣叫,虽然这三个特性麻雀完全符合,但是不能把这三个接口合并到一个接口D中,然后让麻雀来实现,而是应该隔离开,让具备某种能力的类实现指定的接口。
合成复用原则(Composite Reuse Principle,CRP)
合成复用原则定义:尽量使用对象组合,而不是继承来达到复用的目的。
简单来说,就是类之间的关系,少用继承,尽量使用接口实现或者依赖注入的方式。例如有一个面试题,如何解决ArrayList线程不安全的问题,我所知道的有以下5个方法:
(1)使用CopyOnWriteArrayList();
(2)使用Collections.synchronizedList();
(3)定义一个类MyArrayList,继承ArrayList,重写其方法,每个方法用synchronized修饰;
(4)定义一个类MyArrayList,类里面定义一个ArrayList,自定义List的增删改查方法,用synchronized修饰,方法里面调用ArrayList对应的方法;
(5)使用Vector;
重点是第三个、第四个方法的对比,前者是继承,需要重写父类的方法,后者是设值注入,调用ArrayList的方法,显然后者更加灵活。
迪米特法则(Law of Demeter,LoD)
迪米特法则,又称最少知识原则原则,简单来说,就是指一个软件实体应当尽可能少地与其他实体发生相互作用。这样,当一个模块修改时,就会尽量少地影响其他的模块。文章来源:https://www.toymoban.com/news/detail-723219.html
总结
本篇文章内容基本来自《设计模式》(第2版,清华大学出版社,刘伟主编)第1、2章文章来源地址https://www.toymoban.com/news/detail-723219.html
到了这里,关于【设计模式-1】UML和设计原则的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!