13518219792
这篇文章将为大家详细讲解有关java设计模式中观察者模式怎么实现，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：国际域名空间、网站空间、营销软件、网站建设、肇源网站维护、网站推广。
具体的代码如下。
我们看输出实现了我们想要的结果，也就是当订单发生更新时，其他3个系统都会收到信息。但我们在之前的文章中提到过，我们在设计系统时，不要针对实现编程，要针对接口编程，这样程序比较方便扩展。按照我们上述的代码，如果我们要添加新的系统，例如卡卷系统 ，那么这时我们就要修改曾经已经编写好的代码，也就是OrderSuccess接口，那这就违背了设计模式的基本原则了。显然上述的代码，虽然可以实现需求，但是却不是最好的，因为不方便扩展。那么怎么办？我们分析需求知道这显然是一个一对多的关系，当订单更新时，其他和它相关的系统都需要接到通知然后更新，类似报纸订阅是一样的，只要报纸发生变化，那么订阅该报纸的人都能知道。其实，这就是典型的观察者模式。下面我们先看一下观察者模式的定义。
观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
我们在说的简单点比如对一个有状态的对象，我们称之为主题对象，然后我们有一堆和主题对象依赖的对象，我们叫它观察者对象。这样当主题对象更新时，观察者对象会自动收到通知并更新。
按照我们上面的代码怎么把他们修改为观察者模式呢？我们按之前学到的知识应该对接口编程，而不是对实现编程。所以我们应该抽取出两个接口一个是主题接口，一个是观察者接口。这样主题只知道了观察者都实现了观察者接口，而主题不需要知道观察者具体的类是谁，这样在任何时候我们都可以随时增加新的观察者，只要实现观察者接口就可以了。而主题并不做任何的修改，因为主题对象唯一依赖的东西是一个实现了观察者接口的对象列表，所以我们可以随时添加任意的观察者，而主题对象并不需要做任何的更新，这就遵循了设置模式的原则，将对象中可能变化的部分提取出来，这样当其他对象变化时，该对象不需要做任何的更改。这里我们还有一个重要的设置模式原则，也就是为交互对象之间的松耦合设计而努力。在说的直白点就是我们在设计系统时应该将对象与对象之间的耦合度设计的尽量低，耦合度越低，对象与对象的依赖关系也就越低，这样也就方便我们更好的扩展。
那我们应该怎么将上述的代码修改为观察者模式呢？通过以前的知识我们知道应该对接口编程，而不是对实现编程，因为这样我们比较方便扩展。所以我们应该将上述代码中涉及到的物流系统、商品系统、积分系统抽象出一个公共的接口，同理我们也将订单抽象出一个接口，这样的好处是，当创建新的子类时，对接口的编程代码是不需要变化的，这就遵循了我们上述提到过的松耦合了。下面我们将上述代码修改为真正的观察者模式，具体代码如下：
这样我们就将上述的代码修改为真正的观察者模式的代码，这样的好处就是非常方便我们的扩展，我们在新添加新的系统时，而并不需要修改曾经已经开发好的代码，也就是订单中的已有的代码，这样就真正做到了可扩展了。下面我们将新增一个卡卷系统，来证明我们上述所说的可扩展性。
快看，我们成功的将新的卡卷系统添加到了这个观察者了，并且它成功收到了订单变更的通知，并且我们并没有修改任何有关订单的代码，这就是我们上面所说的低耦合，这也就是观察者模式的好处。
到这里，我们已经将观察者模式都介绍完了，本应该到这里就结束了，但这个观察者模式有点特别，Java为了我们更方便的使用观察者模式，所以在Java中直接内置的支持观察者模式，也就是我们自己并不需要创建主题和观察者了，因为Java中直接就提供了这两个接口（确切的说是一个接口和一个类）。下面我们将上述的代码，用Java中内置的观察者模式来实现。
下面为具体的代码：
我们看使用Java内置的观察者和我们自定义的观察者模式的效果是一样的，但代码却大大的减少了，因为大部分的代码都已经被内置的实现了。虽然这样有很大的好处，但有一点不太方便，可能你们也发现了，也就是Observable是一个类，而不是一个接口，如果我们要想使用Java内置的观察者模式，如果主题已经继承了其他的父类，那我们就不能使用Java内置的观察者模式了，因为在Java中并不支持多重继承，这也就是Java内置的观察者模式的弊端。
关于“java设计模式中观察者模式怎么实现”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
