方案1：



FileManager在写文件时，判断要写的文件是否受保护，如果受保护，判断用户是否是管理员。
void
FileManager::Write(File* file, string s)
{
 if (PROTECTEDFILE == file.GetType() &&
  ADMINISTRATOR != userId)
 {
  return;
 }
 file->Write(s);
}

缺点：
FileManager的Write函数，需要根据file的具体类型做区分处理。如果ProtectedFile的权限保护规则有变化，需要修改FileManager。FileManager对于权限保护规则的变化，不符合Open-Close原则。

方案2：



文件权限保护规则，放在ProtectedFileProxy中，且它实现了File接口，这样FileManager就可以把ProtectedFileProxy当作普通文件处理。

void
ProtectedFileProxy::Write(string s)
{
 if (ADMINISTRATOR == userId)
 {
  m_pProtectedFile->Write(s);
 }
}

void
FileManager::Write(File* file, string s)
{
 file->Write(s);
}

总结：
1.作用：为其它对象提供一种代理以控制对这个对象的访问。
2.效果：Proxy模式在访问对象时引入了一定程度的间接性，这个间接性对用户是透明的，即用户不依赖于这种间接性的变化。附加的间接性有多种用途：
（1）Remote Proxy，访问远程对象，就跟访问本地对象一样。如RMI。
（2）Virtual Proxy，可以智能的决定创建对象的时机。
（3）Protection Proxy，允许在访问一个对象时有一些附加地内务处理（如权限检查）。

方案１：
WeatherStation拥有TVStation和RadioStation对象的指针。温度发生变化时，WeatherStation调用TVStation和RadioStation的Update函数，通知他们温度发生了变化。TVStation和RadioStation调用WeatherStation的GetTemperature获取温度数据，并广播出去。

缺点：
WeatherStation直接依赖于需要被通知的具体类（目前只有TVStation和RadioStation）。被通知的具体类发生变化时，例如需要通知移动通信运营商，WeatherStation需要添加新的成员变量，保存移动通信运营商指针。还需要添加AttachXX和DetachXX接口，修改SetTemperature。也就是说，WeatherStation对于被通知者种类的变化，不符合Open-Close原则。

怎么解决：
Open-Close原则的关键在于抽象。WeatherStation不应该依赖于具体的被通知者，而是要依赖于抽象的被通知者。所以，需要把被通知者的跟温度更新有关的接口提取出来，作为抽象基类Observer，具体的被通知者继承Observer。

另外，WeatherStation的注册/取消注册功能，通知观察者功能，可以提取出来作为基类，利于复用。

方案2：
Subject类提供了注册/取消注册观察者功能，以及通知观察者功能。WeatherStation继承了Subject类，从而具备了注册/取消注册及通知功能。Observer提供了更新观察者的接口Update。任何想要在WeatherStation变化时收到通知的类，只需要继承Observer，并在实例化时调用Subject的Attach接口注册即可。




现在，移动通信运营商如果想知道温度变化信息，只需要继承Observer，实例化时调用Subject的Attach接口注册即可。WeatherStation不需要做任何改动。

总结：
1.意图
 定义对象间的一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。
2.适用性
 一个对象的改变需要通知多个对象，而被通知的对象的种类可能会发生变化。
3.优点
 目标不依赖于具体的观察者，而是依赖于抽象，这就降低了耦合度。当观察者种类发生变化时，目标不需要做任何改变。
 支持广播通信。目标变化时，不需要指定通知的接收者，而是通知所有注册的观察者。
4.缺点
 因为是广播通信，即使观察者A不关心变化p，在变化p发生时，观察者A仍会收到通知。这会降低效率。
 如果观察者A关心的数据变化种类特别多，而Update函数又没有参数指定变化类型，观察者A不得不更新所有关心的数据。这也会降低效率。这可以通过给Update函数增加参数，指明更新的数据来解决。

方案2：


存在的问题：
1.所有的特征都放在了抽象层。即使用户不需要readReversedLine、readLowerCaseLine，也需要依赖于它们。
2.如果想增加新的字符串处理操作，需要修改抽象层InputStream，从而引起InputStream用户代码的变更。即，InputStream对于字符串处理操作的变更不是开放-关闭的。

方案3：通过组合来解决（Decorator模式）
读取数据是InputStream的核心职责，字符串处理是InputStream的附加职责。我们可以通过组合的方法，动态地为读取数据职责添加附加地字符串处理职责。



string
ReverseInputStream::readLine()
{
 string result = m_cStream.readLine();
 ReverseString(result);
 return result;
}

总结：
1.作用：动态地给一个对象添加一些额外地指责。
2.优点：
 可以动态地给对象添加职责，非常灵活，用户需要什么职责，就添加什么职责；
 附加职责的变化，不会引起用户代码的变化，即开放-关闭。
3.缺点：
 有很多小对象，如ReverseInputStream、LowerCaseInputStream等，增加了系统的复杂性。
 
4.适用性：
 希望动态地、透明地给单个对象添加职责。添加职责的动作不影响该对象的用户；
 对象有两种职责（核心职责、附加职责），如果用生成子类的方法进行扩充，会引起类爆炸。