您的位置: 首页 > 文章 > Java -- 核心设计模式和原则

Java -- 核心设计模式和原则

分类: 文章 • 2024-07-28 17:55:40

（本次设计模式摘自大话设计模式书本知识，用 C# 讲解的）

简单工厂模式

简单工厂模式是属于创建型模式，简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。

策略模式

前言：面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
策略模式： 它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
策略模式结构图：

对于这个 Context 存在的意义：

客户端可通过 Context 来实现想要实现的方法。
策略模式解析：

策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少各种算法类使用之间的耦合。
该 Strategy 类层次为 Context 定义了一系列的可供重用的算法或行为，继承有助于析取出这些算法的公共功能。
策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

单一职责原则

单一职责原则就一个类而言，应该仅有一个引起它变化的原因。
**注意：**如果一个类承担的指责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把这些职责相互分离。

开放-封闭原则

开放封闭原则是说软件实体（类，模块，函数等等）应该可以扩展，但是不可以修改。
及：对于扩展是开放的，对于更改是封闭的。
无论模块多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最优可能发生的变化种类，然后构造抽象来隔离这些变化。
当我们最初编写代码时，假设变化不会发生。当变化发生时。我们就创建抽象来隔离以后发生的同类变化。
面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。切记，切记。

依赖倒置原则

依赖倒转原则
A.高层模块不应该依赖低层模块。两个都应该依赖抽象
B.抽象不应该依赖细节。细节应该依赖抽象。
说白了，就是针对接口编程，不要对实现编程。

里氏替换原则

里氏代换原则(LSP):子类型必须能够替换掉它们的父类型。
也正因为有了这个原则，使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
依赖倒转其实就是谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。

迪米特法则

“迪米特法则(LoD)’ 也叫最少知识原则。
迪米特法则(LoD)，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
迪米特法则其根本思想，是强调了类之间的松耦合。
类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。

装饰模式

装饰模式(Decorator), 动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
装饰模式结构图：

Component是定义一个对象接口，可以给这些对象动态地添加职责。ConcreteComponent 是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator, 装饰抽象类，继承了Component,从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。”
总结：装饰模式却提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。这样做更大的好处就是有效地把类的核心职责和装饰功能区分开了。而且可以去除相关类中重复的装饰逻辑。

代理模式

代理模式(Proxy),为其他对象提供一种代理以控制对这个对象的访问。
代理模式结构图:
代理模式应用

远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。
虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。这样就可以达到性能的最优化。
安全代理，用来控制真实对象访问时的权限。
智能指引，是指当调用真实的对象时，代理处理另外一些事。

观察者模式

观察者模式又叫做发布-订阅(Publish/Subscribe) 模式。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，
会通知所有观察者对象，使它们能够自动更新自己。
简单样例图：
观察者模式结构图：

解析：

Subject类，可翻译为主题或抽象通知者, 一般用一个抽象类或者一个接口实现。它把所有对观察者对象的引用保存在一一个聚集里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。
Observer类，抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者一般用一个抽象类或者一个接口实现。更新接口通常包含一个Update()方法，这个方法叫做更新方法。
ConcreteSubject类，叫做具体主题或具体通知者，将有关状态存入具体现察者对象;.在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色通常用一个具体子类实现。
ConcreteObserver类，具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协调。具体观察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现。

观察者模式特点

将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。
当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变，应该考虑使用观察者模式
当一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。总的来讲，观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

观察者模式的不足
尽管已经用了依赖倒转原则，但是‘抽象通知者’还是依赖‘抽象观察者’，也就是说，万一没有了抽象观察者这样的接口，我这通知的功能就完不成了。另外就是每个具体观察者，它不一定是‘更新’的方法要调用呀，就像我希望的是‘工具箱’是隐藏，‘自动窗口’
是打开，这根本就不是同名的方法。这应该就是不足的地方吧。”

解决方案 -->> 事件委托实现

“抽象通知者”由于不希望依赖“抽象观察者”，所以“增加”和“减少”的方法也就没有必要了(抽象观察者已经不存在了)。
事件委托说明：

委托就是一种引用方法的类型。一旦为委托分配了方法，委托将与该方法具有完全相同的行为。委托方法的使用可以像其他任何方法一样，具有参数和返回值。委托可以看作是对函数的抽象，是函数的‘类’，委托的实例将代表一个具体的函数。
一个委托可以搭载多个方法，所有方法被依次唤起。更重要的是，它可以使得委托对象所搭载的方法并不需要属于同一个类。
但委托也是有前提的，那就是委托对象所搭载的所有方法必须具有相同的原形和形式，也就是拥有相同的参数列表和返回值类型。

……未完待续，持续更新