哈希表java设计_java设计模式---

文章目录

设计模式在软件中哪里？

面向对象 ==> 功能模块[设计模式+算法(数据结构)] ==> 框架[使用到多种设计模式] => 架构[服务器集群]

设计模式的七大原则

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，具有更好的

1)代码重用性(即：相同功能的代码，不用多次编写)

2)可读性(即：编程规范性，便于其他程序员的阅读和理解)

3)可扩展性(即：当需要增加新的功能时，非常的方便，称为可维护

4)可靠性(即：当我们增加新的功能后，对原来的功能没有影响)

5)使程序呈现高内聚，低耦合的特性

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)

我们设计 设计模式的原则 是：

1)单一职责原则

2)接口隔离原则

3)依赖倒转(倒置)原则

4)里氏替换原则

5)开闭原则

6)迪米特法则

7)合成复用原则

单一职责原则

基本介绍

对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。

应用案例

比如下面三种方案的代码：

方案一中，“公路上跑的” 和 “天上飞的” 都在一个类里面。如果某一天要对"公路上跑的"进行细分，那么就绝对会影响到 “天上飞的"的情况。

所以就有了方案二，即把"公路上跑的” 和 “天上飞的” 分成两个类。理论上满足单一职责原则，但是这里代码比较简单，这么分就太细了。你将类进行了分解，那么main函数中的调用就得 重写，定义两个类。

于是有了第三种方案，类级别不遵守单一职责原则，在方法级别上遵守单一职责原则。

单一职责原则注意事项和细节

1)降低类的复杂度，一个类只负责一项职责。

2)提高类的可读性，可维护性

3)降低变更引起的风险

4)通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

不要在一个函数里使用 if elseif else if else if

这样耦合性太高。可以像上面方法3一样，拆成多个方法。或者拆成多个类。

接口隔离原则(Interface Segregation Principle)

基本介绍

1)客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

2)先看一张图：

3)类A通过接口Interfacel依赖类B，类c通过接口Interface1依赖类D，如果接口Interface1对于类A和类c来说不是最小接口那么类B和类D必须去实现他们不需要的方法。