观察者模式
图示
image.png
涉及角色
-
抽象主题(Subject)角色：抽象主题角色把所有对观察者对象的引用保存在一个聚集（比如ArrayList对象）里，每个主题都可以有任何数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象，抽象主题角色又叫做抽象被观察者(Observable)角色。
-
具体主题(ConcreteSubject)角色：将有关状态存入具体观察者对象；在具体主题的内部状态改变时，给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者(Concrete Observable)角色。
-
抽象观察者(Observer)角色：为所有的具体观察者定义一个接口，在得到主题的通知时更新自己，这个接口叫做更新接口。
-
具体观察者(ConcreteObserver)角色：存储与主题的状态自恰的状态。具体观察者角色实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态 像协调。如果需要，具体观察者角色可以保持一个指向具体主题对象的引用。
对于观察者模式推送和拉取两种模式的比较
-
推送模式是假定主图对象已经知道观察者需要的数据，拉取模式是主题不知道观察着需要什么数据就把自身素有属性传递给观察者，让观察者自己按需要取值
-
推送模式可能会使观察者难以复用，因为update方法的参数是找需要指定的类型，这就意味着每当出现新的情况的时候，就需要提供新的update方法，或者重新实现一个观察者；拉模型因为直接将本身传递给了观察者，等同于将所有能传递的属性集合传递给了观察者，基本上可以适应各种情况的需要
java中对于观察者模式的支持
-
Java在java.util包里边提供了一个observable类以及一个observe接口，构成java语言对观察者模式的支持
-
在使用时，observable有一个子类watched(被观察者),observer有一个子类watcher（观察者）
扩展
消息中间件相关知识
模式
发布订阅模式
image.png
-
基于订阅的模式，一条消息能被多个服务街搜狐
-
服务端只负责推送，不理会接收端的情况，单纯的生产者
-
联想到的相关技术服务：搜狐新闻rss订阅
点对点模式
image.png
-
一个消息只能被一个服务接收
-
消息一旦被消费，就会消失
-
如果没有被消费，就会一直等待，直到被消费
-
多个服务监听同一个消费空间，先到先得
请求-应答模式
image.png
-
基于点对点模式的扩展，所以拥有点对点模式的相关特性
-
责任转移，由消费者通知生产者推送消息，而不是生产者随意发送
-
避免资源浪费
-
安全性能提升
装饰器模式
说明
装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常给对象添加功能，要么直接修改对象添加相应的功能，要么派生对应的子类来扩展，抑或是使用对象组合的方式。显然，直接修改对应的类这种方式并不可取。在面向对象的设计中，而我们也应该尽量使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化，分散化，然后再运行期间，根据需要来动态组合的这样一个模式。
对象的组合：一个类可以把对象作为自己的成员变量，如果用这样的类创建对象，那么该对象中就会有其它对象，也就是说该对象将其他对象作为自己的组成部分（这就是人们常说的Has-A），或者说该对象是由几个对象组合而成。
上面说的重点其实就是：
-
复杂的功能简单化
-
按需动态组合
举例
一辆车，品牌只能要么是奥迪、要么是宝马，不可能同时属于奥迪和宝马，而品牌也是一辆车本身的重要属性特征。但当你想要给汽车喷漆，换坐垫，或者更换音响时，这些功能是互相可能兼容的，并且他们的存在不会影响车的核心属性：那就是他是一辆什么车。这时你就可以定义一个装饰器：喷了漆的车。不管他装饰的车是宝马还是奥迪，他的喷漆效果都可以实现。
图示
image.png
涉及角色
-
抽象组件：component 需要装饰的抽象对象
-
具体组件：comcreteComponent 需要装饰的对象
-
抽象装饰类： decorator 内含只想抽象组件的引用及装饰者共有的方法
-
具体装饰类：concreteDecorator 被装饰的对象
特点
-
装饰着和被装饰者拥有共同的超类
-
利用继承获得类型匹配
-
利用组合扩展行为
缺点
-
会产生大量的小类
-
实例化组件时，会增加代码复杂度
Java中的应用
- javaio类 原文链接：https://blog.csdn.net/wxl1234579/article/details/52755967
image.png
项目思考
- 经营参谋中有组件的概念，当组价组件的功能确定下来以后，后续为组件添加新的功能的时候：比如其他的属性 字体size,字体颜色，样式布局等等，直接去改变组价类显然是不合适的，如果通过继承来进行扩展可以满足当前需求，但是后续再增加属性，难道继续继承？这样下去会导致层次复杂，难以复用，使用装饰器模式可以解决这种问题，不断的新建装饰器来满足需求，虽然也会产生小类，但是层次简单，动态组合
工厂模式（https://blog.csdn.net/zxt0601/article/details/52798423）
简单工厂
定义
在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。
设计角色
Factory：工厂角色 工厂角色负责实现创建所有实例的内部逻辑
Product：抽象产品角色 抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口
ConcreteProduct：具体产品角色 具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。
特点
-
工厂角色负责实现创建所有实例的内部逻辑；
-
抽象产品角色是所创建的所有对象的父类，负责描述所有实例所共有的公共接口；
-
具体产品角色是创建目标，所有创建的对象都充当这个角色的某个具体类的实例。
图示
image.png
优点
- 实现对象的创建和对象的使用分离，将对象的创建交给专门的工厂类负责，
缺点
- 缺点在于工厂类不够灵活，增加新的具体产品需要修改工厂类的判断逻辑代码，而且产品较多时，工厂方法代码将会非常复杂
工厂模式
定义
工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪一个产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。
图示
image.png
角色
-
抽象产品是定义产品的接口，是工厂方法模式所创建对象的超类型，即产品对象的共同父类或接口；
-
具体产品实现了抽象产品接口，某种类型的具体产品由专门的具体工厂创建，它们之间往往一一对应；
-
抽象工厂中声明了工厂方法，用于返回一个产品，它是工厂方法模式的核心，任何在模式中创建对象的工厂类都必须实现该接口；
-
具体工厂是抽象工厂类的子类，实现了抽象工厂中定义的工厂方法，并可由客户调用，返回一个具体产品类的实例。
优点
- 增加新的产品类时无须修改现有系统，并封装了产品对象的创建细节，系统具有良好的灵活性和可扩展性；
缺点
- 其缺点在于增加新产品的同时需要增加新的工厂，导致系统类的个数成对增加，在一定程度上增加了系统的复杂性。
抽象工厂
定义
图示
image.png
特点
-
利用对象组合
-
负责将客户从具体类型中解耦
-
把一群相关的产品集合起来
-
经常使用工厂方法模式来实现具体工厂
网友评论