Pattern-Oriented Software Architecture v1巨详细读书笔记 1

 Pattern-Oriented Software Architecture （简称：POSA）是除了GoF 的 Design Patterns: Elements of Reusable Object-Oriented Software以外的Design Pattern经典书籍。它是一个系列，现在一共有5本，其中的3本好像都有中文版。

这个读书笔记是有感于那个Vol1的中文版翻译太差劲，以至到句子都不通顺的地步，看那个中译本完全不知所云，还不如看原版。因此，虽然我的英语不好，但还是硬着头皮去啃那英语，边看就边写下了读书笔记，有直接翻译的部分，主要是为了以后看起来方便。
这一部分是从［page 266］Proxy模式的Dynamic一节开始，其中跳过了很多我认为不是很重要或者是评论的小节，还有的我觉得不好翻的我就直接附上了原文以方便理解，图就没有包含了，如果要看图就自己去看原版吧，我都标有页码，很容易就能找见：）
我争取每天更新一部分。

下面，好戏开始：

［page 266］
下图显示了典型的Proxy模式结构的动态场景，注意，实际情况决定了proxy内不同的执行动作，更多的信息可以参见［变体］一节：
    － 在运行时，client请求proxy执行服务。
    － proxy接收到一个服务请求，先作预处理，执行一系列动作，如：查找original的地址，或检查本地缓存，看请求的信息是否已经被缓存并可直接使用。
    － 如果Proxy需要咨询origial来完成服务请求，则会将请求用适当的通讯协议和安全的方法转发给original。
    － original接收请求并完成服务，并把服务结果发回给proxy。
    － Proxy接收到original的返回结果。在将它发送回client之前或之后，proxy也许会执行附加的后期处理，如：缓存结果，调用origial的析构函数或释放占用资源上的锁。

［page 267］
［图］

［实现］
通过以下步骤可以实现Proxy模式：
    1 鉴别出组件中所有处理访问控制的职责,将这些职责放入一个proxy组件中。此步骤详细信息在［变体］一节描述。
    2 如果有可能，则引入一个抽象基类表示proxy和original的公共部分，并使proxy和original从此抽象基类继承。如果proxy和 original采用相同的接口不可行，则可以采用adapter［GHJV95］模式来做接口适配。通过将proxy适配到original的接口，让 client保持接口一致的错觉，并且使adapter和original抽取出一个公共基类成为可能。
    3 实现proxy的功能。在此步骤结束后检查第一步骤鉴别出的proxy的角色。
    4 将迁移到Proxy中的职责从original和client中清除。
    5 在proxy中存储一个关联到original的handle，这个handle可能是一个指针，引用，地址，标识，socket，端口等等。
    6 将所有original和client之间的直接关系都清除掉，将这些关系都替换成类似的client和proxy之间的关系。



［page 268］
［变体］
下面描述几种普通proxy的变体。首先我们简单描述各种变体以及他们最适合的环境：
    － 远程proxy，网络地址和IPC（inter-process communication，进程间通讯）协议应该被屏蔽在访问远程组件的client之外。
    － 保护proxy，防止对组件未经许可的访问。
    － 缓存proxy，让多个本地client能共享远程组件的结果。
    － 同步proxy，同步对同一个组件的并发访问。
    － 计数proxy，防止意外地删除组件，并收集使用情况的统计数据。
    － 虚拟proxy，当加载过程和处理过程代价较大时，用满足部分需求的组件信息返回给client。
    － 防火墙proxy，保护本地client不受外部干扰。



以下的段落详细描述了每个变体的特性和实现。

远 程proxy 封装并维护了original的物理地址，并实现IPC（inter-process communication）标准同original进行实际通讯。针对每个original，proxy将实例一个original服务所要求的地址空 间。对于复杂的IPC机制，你可以像Forwarder－Receiver模式所描述的一样，在original组件中引入一个receiver，在 proxy中引入一个forwarder，将所有proxy和original的通讯职责移交给forwarder和receiver，以简化 proxy。

For reasons of efficiency, we discern remote proxies into three cases:
    － client和original在同一个进程中。
    － client和original在同一台机器中的不同进程中。
    － client和original在不同机器的不同进程中。

［page 269］
第 一种情况很简单：不需要proxy与original对话。对于第二、三种情况，我们把远程地址信息放到proxy中，通常包括：机器ID，端口或进程编 号，对象ID。第二种情况明显不需要机器ID，如果你要节省机器ID所占用的几个字节，那么第二和第三种情况间的差异将导致proxy的代码变得复杂。在 开发中除非两种情况下的IPC不同，迫使我们实现这种差异，否则实现这种差异并不合理。即使那样，你仍然可以在这三种差异的情况上加上一寻址策略层来简化 代码。Abstract original可以屏蔽掉这三种情况，让client对于这三种情况完全不知情。
In high-performance applications, you often want to determine
whether or not communication is expensive at the application level
before committing to an off-board request. In such cases, a remote
proxy reveals this information.



保 护proxy  proxy通过检查每个client的访问权限来防止对original未经许可的访问。最简单的实现办法是使用平台提供的访问控制机制。如果可能，给每 个访问组件的客户设定它自己的访问许可。访问控制列表（ACL－Access control lists）就是广泛使用的一种实现这种机制的技术。


缓 存proxy  可以通过扩展数据区的方式实现在proxy中临时缓存结果数据，并设计一种策略来维护和更新缓存。当缓存满了，有多种策略让你释放空间给新的数据，比如： 可以删除最少使用的缓存数据；或采用'move-to-front'策略，采用一个双链表，客户从前端访问数据，将新的数据放在前端，尾部的数据被删除， 这个策略很容易实现并且效率不错。

同时需要处理'缓存失效'问题，当original中的数据改变时，需要向已经失效的proxy缓存拷 贝这些改变数据。如果这些数据是很重要的数据，并且在客户中总是需要最新的数据，那可以在original中的数据有任何改变时都将proxy缓存中所有 的数据标为失效。