共计 2470 个字符，预计需要花费 7 分钟才能阅读完成。
1. 设计主旨
可维护性和可复用性
1.1. 可维护性(Maintainability)
如果要思考到软件的可维护性, 从设计之初就要思考软件的 可扩展性 灵活性 可插拔性 等等;
1.2. 可复用性(Reuseability)
复用不仅仅是代码的复用: 代码的复用 算法的复用 数据结构的复用
要做到这两点, 在设计的时候, 就必须遵循一些准则, 咱们称之为面向对象的设计准则
2. 设计准则 SOLIDCD
设计准则一览:(注: 这个缩写是我本人的记忆简写)
S => SRP=Single Responsibility Principle = 繁多职责准则
O => OCP=Open Close Principle = 开闭准则
L => LSP= Liscov Substitution Principle = 里氏代换准则
I => ISP = Interface Segregation Principle = 接口隔离准则
D => DIP = Dependency Inversion Principle = 依赖倒转准则
C => CARP = Composite/Aggregation Reuse Principle = 合成 / 聚合复用准则
D => Lod=Law of Demeter = 迪米特法令
1. 繁多职责准则
Single Responsibility Principle
一个类 / 接口应该专一于做一件事件, 升高类 / 接口的复杂度, 一个类 / 接口只负责一项职责，其逻辑放弃简略；
可读性高，可维护性高；变更导致的危险就低:
当批改一个性能时，能够显著升高对其余性能的影响
须要阐明的一点是繁多职责准则不只是面向对象编程思维所特有的，只有是模块化的程序设计，都实用繁多职责准则。
2. 开闭准则
Open Close Principle
软件设计应答扩大凋谢, 对批改敞开
如何做到 OCP? 抽象化 是要害;
比方: 玉帝诏安美猴王; 梁山好汉被诏安; 就是典型的 OCP:
宫廷不废一兵一卒, 不毁坏原来的体系制度 ==> 对批改敞开!
只须要在原来的制度上新增几个小小的职位实例, 就能够实现革新 ==> 对扩大凋谢!
设计模式案例: 策略模式
对规定的援用, 依赖于一个策略的接口, 策略的实现是可定制的, 想要新增新的规定, 只须要实现一套新的策略, 替换之即可!
见: jdk 中的设计模式 - 策略模式 -RejectedExecutionHandler
3. 里氏替换准则
Liscov Substitution Principle
任何基类 (父类) 能够呈现的中央, 子类定可替换之!
设计模式案例:
-
代理模式
代理模式: 代理类和被代理类实现同一个接口, 咱们利用的上下文应用的是形象接口, 这样的话, 代理类就能够替换原来的接口实现类, 代替它来实现操作;
-
策略模式
策略模式: 策略接口是一个形象的接口, 策略的实现是 N 个不同的策略实现类, 咱们利用的上下文应用的是策略的形象接口, 这样任何一个策略实现类都能够替换策略接口;
4. 接口隔离准则
Interface Segregation Principle
- 给利用上下文 (调用方) 提供尽可能小的接口; 防止裸露大接口;
- 多个专门的接口 > (优于) 一个性能简单的总接口
接口隔离准则 跟 繁多职责准则 有类似的中央, 都是讲求实现逻辑的精简, 防止裸露过多非必要的性能给调用方.
一来是为了设计简略, 可读性强;
二来是为了防止提供的性能过多, 导致前期的变更导致尾大不掉, 减少维护性的老本, 给扩大也带来更大压力!
[ˌseɡrɪˈɡeɪʃn] n. 隔离; 拆散; 种族隔离
5. 依赖倒置准则
Dependency Inversion Principle
应用程序, 应该面向接口编程, 不要针对实现编程;
依赖倒转的 倒转 指的是: 咱们原来一个对象依赖另外一个对象, 间接在 new 指标类, 干就完了;
然而当初咱们要把这个 new 指标类 换成一个指标类的接口, 咱们应用接口的办法;
把依赖的具体倒置为依赖接口(形象)!
设计模式案例:
-
模板办法模式
咱们应用程序中应用模板类, 模板类中留好未实现的办法逻辑, 在程序理论执行过程中咱们调用的这块的逻辑实际上来自于上层的抽象类的实现; 这样, 依赖的关系就倒转了.
-
工厂办法模式
工厂办法模式也是: 咱们依赖于工厂的形象来调用, 调用时理论会唤起具体的工厂实现子类.
6. 合成 / 聚合复用准则
什么是合成和聚合?
类和类之间有 3 中关系: 一般化关系 / 关联关系 / 依赖关系:
6.1 一般化关系
- 类和类之间的继承关系
- 接口和接口之间的继承关系
- 类和接口之间的实现关系
6.2 关联关系
关联关系 就是一个类晓得另一个类的属性和办法, 简略说, 就是 实例变量的援用;
-
关联关系
一个类援用了另一个类的实例变量, 作为本人的属性;
-
聚合关系
强的关联关系; 一个类作为整体, 关联了一些个体类的实例;
-
合成关系
比聚合更强的关联关系: 一个类作为整体, 关联了一些其余类, 被关联的类和他是整体和局部的关系, 整个生命周期都在其管制之内;
具体阐明:
关联 : 体现在 java 代码中就是: 一个类中援用了另一个类的示例(援用示例), 比方: spring 的 Service 类中 @Autowire 一个别得服务;
聚合 : 聚合也是一种关联; 只是增强了这种关联; 聚合是一种强关联: 整体和个体的那种关联, 典型例子就是: 汽车和轮胎 / 汽车和发动机;
汽车是整体, 发动机和轮胎都是个体;
合成 : 合成也是一种关联; 且是更强的关联, 合成也是一种强关联, 比聚合更强, 合成的关联, 是整体和局部的关系, 整体整个负责了局部的生命周期; 典型例子: 人和胳膊 / 大腿 / 脚丫子; 人事整体, 胳膊 / 大腿 / 脚丫子都是局部, 且他们的生命周期都更强的关联于人体;
依赖: 依赖也是一种
6.3 CARP 合成聚合复用准则
是说如果要进步可复用性, 应该着眼于合成和聚合的这种关联关系, 而不是通过继承类来实现!
这里有 jdk 中的两个反例: 他们通过继承来实现复用, 不合乎设计准则:
-
Stack 类:
Stack<E> extends Vector<E> -
Properties 类:
Properties extends Hashtable<Object,Object>
7. 迪米特法令(起码通信)
迪米特法令, 也称 起码晓得 准则: 软件实体之间应该尽可能少的产生相互作用;
最简略的优化逻辑就是: 升高成员变量的拜访权限; 比方非必要, 就 public->private
