13. 面向对象设计原则(3:包结构原则)
The Release Reuse Equivalency Principle(REP)
The granule of reuse is the granule of release(软件包的粒度与可重用的粒度保
持一致)
The Common Closure Principle(CCP)
Classes that change together, belong together(一致变化的类,应该属于同
一个包)
The Common Reuse Principle(CRP)
Classes that aren’t reused together should not be grouped together(不被
一起重用的类,不放到一个包里)
高内聚(Cohesion)
14. 面向对象设计原则(4:包结构原则)
The Acyclic Dependencies Principle(ADP)
The dependencies between packages must not form cycles(软件
包之间不能相互依赖,构成依赖循环)
The Stable Dependencies Principle(SDP)
Depend in the direction of stability(包之间的依赖关系都应该是稳定方
向依赖的,包要依赖的包要比自己更具稳定性)
The Stable Abstractions Principle(SAP)
Stable packages should be abstract packages(稳定的包,应该是
抽象的包,以此带来可变性)
低耦合(Coupling)
21. Factory Method模式
举例
你是一个ATM机软件的开发工程师,需要测试ATM软件的存取款功能,但在测试时
不想产生实际的银行业务,该怎么办呢?
public class ATMGui{
……
private Status doWithdrawal(Account account, float amount) {
Transaction transaction = new Transaction();
transaction.setSourceAccount(account);
transaction.setDestAccount(myCashAccount());
transaction.setAmount(amount);
transaction.process();
if (transaction.successful()) {
dispense(amount);
}
return transaction.getStatus();
}
}
Public class ATMGuiTest{
… …
public void testCheckingWithdrawal() {
float startingBalance = balanceForTestCheckingAccount();
AtmGui atm = new AtmGui();
insertCardAndInputPin(atm);
atm.pressButton("Withdraw");
atm.pressButton("Checking");
atm.pressButtons("1", "0", "0", "0", "0");
assertContains("$100.00", atm.getDisplayContents());
atm.pressButton("Continue");
assertEquals(startingBalance - 100,
balanceForTestCheckingAccount());
}
}
22. Factory Method模式
class Class Model
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
ATMGui
+ doWithdrawal() :void
+ createTransaction() :void
MockedATMGui
+ createTransaction() :void
ConcreteATMGui
+ createTransaction() :void
ATMGuiTest
+ testCheckingWithdrawal() :void Transaction transaction =
createTransactioin();
......
return new MockedTransaction(); return new RealTransactioin();
ATMGui gui = new MockedATMGui();
......
118. Layers模式
Example: OSI 7-Layer Model
Benefits:
Aiding development by teams
(多团队并行开发)
Incremental coding and testing
(增量编码与测试)
Easier exchange of individual
parts(易于替换独立部分)
Reuse of individual layers in
different layers in different
contexts(可以在不同场景下复
用不同分层)
119. Layers模式
Context:
A large system that requires decomposition(一个需要分解的大系统)
Problem:
Late source code changes should not ripple through the system (changeable)
Interfaces should be stable, and may even be prescribed by a standards body
Parts of the system should be exchangeable
It may be necessary to build other systems at a later date with the same low-level
issues as the system you are currently designing (Reusable)
Similar responsibilities should be grouped to help understandability and
maintainability. But each component should be coherent.
There’s no ‘standard’ component granularity
Complex components need further decomposition
Crossing component boundaries may impede performance
System will be built by a team of programmers and work has to be subdivided along
clear boundaries
120. Layers模式
Solution
Structure your system into an appropriate number of layers and place them
on top of each other
Start at the lowest level of abstraction (Layer 1), which is the base of your
system
Work your way up the abstraction ladder by putting Layer J on top of Layer J-
1 until you reach the top level of functionality (Layer N)
Above does not prescribe the order in which to actually design layers, it just
gives a conceptual view
Within an individual layer all constituent components work at the same level
of abstraction
Most of the services that Layer J provides are composed of services provided
by Layer J-1. The services of each layer implement a strategy for combining
the services of the layer below in a meaningful way. In addition, Layer J’s
services may depend on other services in Layer J
121. Layers模式
Structure: by CRC card
The services of Layer J are only used by Layer
J+1 ---- There are no further direct
dependencies between layers
122. Layers模式
Dynamics
Top-down communication: ‘requests’
Bottom-up communication: ‘notifications’
Requests only travel through a subset of the layers: ‘caching layers’
Notifications only travel through a subset of the layers
Two stacks of N layers communicating with each other
123. Layers模式
Implementation
Define the abstraction criterion for grouping tasks into layers (定原则)
Determine the number of abstraction levels according to your abstraction
criterion (定分层)
Name the layers and assign tasks to each of them (分任务)
Specify the services (定服务)
Refine the layering (Iterate over steps 1 to 4) (迭代优化)
Specify an interface for each layer (定接口)
Structure individual layers (定层内结构)
Specify the communication between adjacent layers (定通信方式)
Decouple adjacent layers (层间解耦)
Design an error-handling strategy (定错误处理策略)
125. Layers模式
Variants
Relaxed Layered System: the gain of flexibility and performance is paid for by
a loss of maintainability.
Layering Through Inheritance: higher layers can modify lower-layer services
according to their needs. But such an inheritance relationship closely ties the
higher layer to the lower layer.
Known Uses
Virtual Machines
APIs
Information Systems
Windows NT
126. Layers模式
Liabilities
Cascades of changing behavior
Lower Efficiency
Unnecessary work
Difficulty of establishing the correct granularity of layers
See also
Composite Message Pattern
Microkernel architecture
PAC architectural pattern
128. Pipes & Filters模式
Context
Processing data streams (处理数据流)
Problem
Future system enhancements should be possible by exchanging processing
steps or by recombination of steps, even by users (支持处理流程更改)
Small processing steps are easier to reuse in different contexts (步骤重用)
Non-adjacent processing steps do not share information
Different sources of input data exist, such as a network connection or a
hardware sensor providing temperature readings, e.g..
It should be possible to present or store final results in various ways
Explicit storage of intermediate results for further processing in files clutters
directories and is error-prone, if done by users
You may not want to rule out multi-processing the steps, for example
running them in parallel or quasi-parallel.
129. Pipes & Filters模式
Solution
The pipes and filters architectural pattern divides the task of a system into
several sequential processing steps.
These steps are connected by the data flow through the system
Each processing step is implemented by a filter component
A filter consumes and delivers data incrementally to achieve low latency and
enable real parallel processing
The input is provided by a data source such as a text file
The output flows into a data sink such as a file, terminal, animation program and
so on.
The data source, the filters and the data sink are connected sequentially by pipes
Each pipe implements the data flow between adjacent processing steps
The sequence of filters combined by pipes is called processing pipeline
133. Pipes & Filters模式
Implementation
Divide the system’s task into a sequence of processing stages;(将处理过程
分段)
Define the data format to be passed along each pipe;(定义数据格式)
Decide how to implement each pipe connection;(定义管道连接)
Design and implement the filters;(实现过滤器)
Design the error handling;(实现错误处理)
Set up the processing pipeline;(建立执行管道)
135. Pipes & Filters模式
Consequences
Benefits:
No intermediate files necessary, but possible;
Flexibility by filter exchange;
Flexibility by recombination;
Reuse of filter components;
Rapid prototyping of pipelines;
Efficiency by parallel processing;
Liabilities:
Sharing state information is expensive or inflexible;
Efficiency gain by parallel processing is often an illusion
The cost for transferring data between filters may be relatively high
Some filters consume all their input before producing any output
Context switching between threads or processes
Synchronization of filters via pipes may stop and start filters often
Data transformation overhead
Error Handling
136. Pipes & Filters模式
See also
The Layers pattern is better suited to systems that require reliable operation,
because it is easier to implement error handling than with Pipes and Filters.
138. Blackboard模式
Problem:
A complete search of the solution space is not feasible in a reasonable time
Since the domain is immature, you may need to experiment with different
algorithms for the same subtask. Individual modules should be easily
exchangeable
There are different algorithms that solve partial problems
Input, as well as intermediate and final results, have different
representations, and the algorithms are implemented according to different
paradigms
An algorithm usually works on the result of other algorithms
Uncertain data and approximate solutions are involved.
Employing disjoint algorithms induces potential parallelism. If possible you
should avoid a strictly sequential solution
139. Blackboard模式
Solution
Collection of independent programs that work cooperatively on a common
data structure. Each program is specialized for solving a particular part of the
overall task and all programs work together on the solution
A central control component evaluates the current state of processing and
coordinates the specialized programs.
During the problem-solving process the system works with partial solutions
that are combined, changed or rejected. Each of these solutions represents a
partial problem and a certain stage of its solution. The set of all possible
solutions is called the solution space, and is organized into levels of
abstraction.
140. Blackboard模式
Structure
Divide your system into a component called blackboard, a collection of
knowledge sources and a control component
Blackboard: the central data store. Elements of the solution space and
control data are stored here. The blackboard provides an interface that
enables all knowledge sources to read from and write to it.
Knowledge sources are separate, independent subsystem that solve specific
aspects of the overall problem. Together they model the overall problem
domain. None of them can solve the task of the system alone. Knowledge
sources do not communicate directly – they only read from and write to the
blackboard.
Control: runs a loop that monitors the changes on the blackboard and
decides what action to take next. It schedules knowledge source evaluations
and activations according to a knowledge application Strategy.
143. Blackboard模式
Implementation
Define the problem
Define the solution space of the problem
Divide the solution process into steps
Divide the knowledge into specialized knowledge sources with certain
subtasks
Define the vocabulary of the blackboard
Specify the control of the system. If the control component displays complex
and independent subtasks, define one control knowledge source for each of
these subtasks.
Implement the knowledge sources. Split the knowledge sources into
condition-parts and action-parts according to the needs of the control
component.
145. Blackboard模式
Consequences
Help to resolve most of the forces listed in the problem section
Experimentation
Support for changeability and maintainability
Reusable knowledge sources
Support for fault tolerance and robustness
Liabilities
Difficulty of testing
No good solution is guaranteed
Difficulty of establishing a good control strategy
Low efficiency
High development effort
No support for parallelism
148. Broker模式
Context
Your environment is a distributed and possibly heterogeneous system with
independent cooperating components
Problem
Building a complex software system as a set of decoupled and interoperating
components, rather than as a monolithic application, results in greater
flexibility, maintainability and changeability. By partitioning functionality
into independent components the system becomes potentially distributable
and scalable
Forces
Component should be able to access services provided by others through
remote location-transparent service invocations;
You need to exchange, add, or remove components at run-time
The architecture should hide system – and implementation-specific details from
the users of components and services
149. Broker模式
Solution
Introduce a broker component to achieve better decoupling of clients and
servers. Server register themselves with the broker, and make their service
available to clients through method interfaces. Clients access the
functionality of servers by sending requests via the broker. A broker’s task
include locating the appropriate server, forwarding the request to the server
and transmitting results and exceptions back to the client.
154. Broker模式
Implementation
Define an object model, or use an existing model
Decide which kind of component-interoperability the system should offer
Specify the APIs the broker component provides for collaborating with clients and
servers
Use proxy objects to hide implementation details from clients and servers
Design the broker component in parallel with steps 3 and 4
Specify a detailed on-the-wire protocol for interacting with client-side proxies and server-
side proxies
A local broker must be available for every participating machine in the network
When a client invokes a method of a server, the broker system is responsible for returning
all results and exceptions back to the original client
If the proxies do not provide mechanisms for marshaling and unmarshaling parameters and
results, you must include that functionality in the broker component
… …
155. Broker模式
Example Resolved
Variants
Direct Communication Broker System
Message Passing Broker System
Trader System
Adapter Broker System
Callback Broker System
Known Cases
CORBA
IBM SOM/DSOM
Microsoft’s OLE 2.*
WWW
ATM-P
156. Broker模式
Consequences
Benefits:
Location Transparency
Changeability and extensibility of components
Portability of a Broker system
Interoperability between different Broker systems
Reusability
Liabilities
Restricted efficiency
Lower fault tolerance
Testing and Debugging
See also
The Forwarder-Receiver pattern
The Proxy pattern
The Client-Dispatcher-Server pattern
The Mediator design pattern
159. MVC模式
Problem
Forces:
The same information is presented differently in different windows, for example,
in a bar or pie chart
The display and behavior of the application must reflect data manipulations
immediately
Changes to the user interface should be easy, and even possible at run-time
Supporting different ‘look and feel’ standards or porting the user interface
should not affect code in the core of the application
160. MVC模式
Solution
MVC divides an interactive application into the three areas
Processing: The model component encapsulates core data and functionality. The
model is independent of specific output representations or input behavior
Output: View components display information to the user. A view obtains the
data from the model. There can be multiple views of the model
Input: Each view has an associated controller component. Controllers receive
input, usually as events that encode mouse movement, activation of mouse
buttons, or keyboard input. Events are translated to service requests for the
model or the view. The user interacts with the system solely through controllers
The change-propagation mechanism for multiple view is described in the
Publisher-Subscriber pattern
164. MVC模式
Implementation
Separate human-computer interaction from core functionality
Implement the change-propagation mechanism
Design and implement the views
Design and implement the controllers
Design and implement the view-controller relationship
Implement the set-up of MVC
Dynamic view creation
‘Pluggable’ controllers
Infrastructure for hierarchical views and controllers
Further decoupling from system dependencies
166. MVC模式
Consequences
Benefits:
Multiple views of the same model
Synchronized views
‘Pluggable’ views and controllers
Exchangeability of ‘look and feel’
Framework potential
Liabilities
Increased complexity
Potential for excessive number of updates
Intimate connection between view and controller
Close coupling of views and controllers to a model
Inefficiency of data access in view
Inevitability of change to view and controller when porting
Difficulty of using MVC with modern user-interface tools
See also
The Presentation-Abstraction-Control pattern
169. PAC模式
Problem
Forces:
Agents often maintain their own state and data. However, individual agents
must effectively cooperate to provide the overall task of the application. To
achieve this, they need a mechanism for exchanging, data, messages, and events.
Interactive agents provide their own user interface, since their respective
human-computer interactions often differ widely.
Systems evolve over time. Their presentation aspect is particularly prone to
change. The use of graphics, and more recently, multimedia features, are
examples of pervasive changes to user interfaces. Changes to individual agents,
or the extension of the system with new agents, should not affect the whole
system.
170. PAC模式
Solution
Structure the interactive application as a tree-like hierarchy of PAC agents.
There should be one top-level agent, several intermediate level agents, and even
more bottom-level agents. Every agent is responsible for a specific aspect of the
application's functionality, and consists of three components: presentation,
abstraction, and control. The whole hierarchy reflects transitive dependencies
between agents. Each agent depends on all higher-level agents up the hierarchy
to the top-level agent.
The agent's presentation component provides the visible behavior of the PAC
agent. Its abstraction component maintains the data model that underlies the
agent, and provides functionality that operates on this data. Its control
component connects the presentation and abstraction components, and
provides functionality that allows the agent to communicate with other PAC
agents.
The top-level PAC agent provides the functional core of the system; Bottom-level
PAC agents represent self-contained semantic concepts on which users of the
system can act, such as spreadsheets and charts; Intermediate-level PAC agents
represent either combinations of, or relationships between, lower-level agents.
173. PAC模式
Dynamic
Scenario 2: shows the behavior of the system after new election data is
entered, providing a closer look at the internal behavior of the top level PAC
agent.
174. PAC模式
Implementation
Define a model of the application.
Define a general strategy for organizing the PAC hierarchy.
Specify the top-level PAC agent.
Specify the bottom-level PAC agents.
Specify bottom-level PAC agents for system services.
Specify intermediate-level PAC agents to compose lower-level PAC agents.
Specify intermediate-level PAC agents to coordinate lower-level PAC agents.
Separate core functionality from human-computer interaction.
Provide the external interface.
Link the hierarchy together.
175. PAC模式
Variants
PAC agent as active objects (multi-threading)
PAC agent as processes (remote)
Known Uses
Network Traffic Management
Mobile Robot
176. PAC模式
Consequences
Benefits:
Separation of concern
Support for change and extension
Support for multi-tasking
Liabilities
Increased system complexity
Complex control component
Efficiency
Applicability
See also
The Model-View-Controller pattern
179. Microkernel模式
Problem
Forces:
The application platform must cope with continuous hardware and software
evolution.
The application platform should be portable, extensible and adaptable to
allow easy integration of emerging technologies.
The applications in your domain need to support different, but similar,
application platforms.
The applications may be categorized into groups that use the same functional
core in different ways, requiring the underlying application platform to
emulate existing standards.
The functional core of the application platform should be separated into a
component with minimal memory size, and services that consume as little
processing power as possible.
180. Microkernel模式
Solution
Encapsulate the fundamental services of your application platform in a
microkernel component.
The microkernel includes functionality that enables other components running in
separate processes to communicate with each other. It is also responsible for
maintaining system wide resources such as files or processes. In addition, it
provides interfaces that enable other components to access its functionality.
Core functionality that cannot be implemented within the microkernel without
unnecessarily increasing its size or complexity should be separated in internal
servers.
External servers implement their own view of the underlying microkernel. To
construct this view, they use the mechanisms available through the interfaces of
the microkernel. Every external server is a separate process that itself represents
an application platform. Hence, a Microkernel system may be viewed as an
application platform that integrates other application platforms.
Clients communicate with external servers by using the communication facilities
provided by the microkernel.
184. Microkernel模式
Implementation
Analyze the application domain.
Analyze external servers.
Categorize the services (semantically-independent).
Partition the categories.
Find a consistent and complete set of operations and abstractions for every
category you identified in step 1.
Determine strategies for request transmission and retrieval.
Structure the microkernel component.
To specify the programming interfaces of the microkernel, you need to decide
how these interfaces should be accessible externally.
The microkernel is responsible for managing all system resources.
Design and implement the internal servers as separate processes or shared
libraries.
Implement the external servers.
Implement the adapters.
Develop client applications or use existing ones for the ready-to-run
188. Reflection模式
Problem
Forces:
Changing software is tedious, error prone, and often expensive.
Adaptable software systems usually have a complex inner structure.
The more techniques that are necessary for keeping a system changeable, such
as parameterization, subclassing, mix-ins, or even copy and paste, the more
awkward and complex its modification becomes.
Changes can be of any scale, from providing shortcuts for commonly-used
commands to adapting an application framework for a specific customer.
Even fundamental aspects of software systems can change, for example the
communication mechanisms between components.
189. Reflection模式
Solution
Make the software self-aware, and make selected aspects of its structure
and behavior accessible for adaptation and change. This leads to an
architecture that is split into two major parts: a meta level and a base level.
The meta level provides a self-representation of the software to give it
knowledge of its own structure and behavior, and consists of so-called
metaobjects.
The base level defines the application logic. Its implementation uses the
metaobjects to remain independent of those aspects that are likely to change.
An interface is specified for manipulating the metaobjects. It is called the
metaobject protocol (MOP), and allows clients to specify particular changes,
such as modification of the function call mechanism metaobject mentioned
above.
193. Reflection模式
Implementation
Define a model of the application.
Identify varying behavior.
Identify structural aspects of the system.
Identify system services that support both the variation of application services
identified in step 2 and the independence of structural details identified in step
3.
Define the metaobjects.
Define the metaobject protocol.
Define the base level.
195. Reflection模式
Consequences
Benefits:
No explicit modification of source code
Changing a software system is easy
Support for many kinds of change
Liabilities
Modifications at the meta level may cause damage. The robustness of a metaobject
protocol is therefore of great importance.
Increased number of components.
Lower efficiency
Not all potential changes to the software are supported
Not all languages support reflection, e.g C++
See also
The Microkernel architecture pattern
203. 练习(5)
描述Observer模式是如何实现以下设计原则的?
-- Design Principle: Identify the aspects of your application that vary and separate
them from what stays the same.
-- Design Principle : Program to an interface, not an implementation.
-- Design Principle: Favor composition over inheritance.
阅读材料《Head First Design Patterns》一书中关于Observer模式的讲述,
思考Design Pattern和Design Principle之间的关系。
205. 练习(7)
将左边的设计模式和右边的设计意图相匹配
Pattern
Decorator
Adapter
Facade
Intent
Converts one interface to another
Doesn’t alter the interface, but adds responsibility
Makes an interface simpler
Pattern
Template Method
Strategy
Factory Method
Intent
Encapsulate interchangeable behaviors and use
delegation to decide which behaviro to use
Subclasses decide how to implement steps in an
algorithm
Subclasses decide which concrete classes to create
设计模式是为某一设计意图服务的,不应滥用设计模式。
206. 练习(8)
阅读《Head First Design Patters》第一章《Intro to Design Patterns》
的内容,回答问题:
为什么说“HAS-A can be better than IS-A”?
214. 架构模式
《面向模式的软件体系结构 – 卷1:模式系统》
中文版翻译得不算太好,建议看原版
《企业应用架构模式》
Martin Flow的经典书籍,触发了DDD的灵感
《SOA in Practice: The Art of Distributed System》
SOA本身就是架构模式的组合运用
OCP是终极目标,其它几条可以看成是OCP的实现方法。
Abstraction is the key to OCP:
1)动态多态(继承)
2) 静态多态(模板)
Abstraction is the key to OCP:
1)动态多态(继承)
2) 静态多态(模板)
Abstraction is the key to OCP:
1)动态多态(继承)
2) 静态多态(模板)
1) 远程代理(Remote Proxy )为一个对象在不同的地址空间提供局部代表。 NEXTSTEP[Add94] 使用N X P r o x y 类实现了这一目的。Coplien[Cop92] 称这种代理为“大使” (A m b a s s a d o r )。2 )虚代理(Virtual Proxy )根据需要创建开销很大的对象。在动机一节描述的I m a g e P r o x y 就是这样一种代理的例子。3) 保护代理(Protection Proxy )控制对原始对象的访问。保护代理用于对象应该有不同 的访问权限的时候。例如,在C h o i c e s 操作系统[ C I R M 9 3 ]中K e m e l P r o x i e s 为操作系统对象提供 了访问保护。4 )智能指针(Smart Reference )取代了简单的指针,它在访问对象时执行一些附加操作。 它的典型用途包括:-- 对指向实际对象的引用计数,这样当该对象没有引用时,可以自动释放它(也称为S m a r tP o i n t e r s[ E d e 9 2 ] )。
-- 当第一次引用一个持久对象时,将它装入内存。
-- 在访问一个实际对象前,检查是否已经锁定了它,以确保其他对象不能改变它。
其它例子:SVN
A user asks the presentation component of the view coordinator
agent to open a new bar chart.
The control of the view coordinator agent instantiates the desired
bar-chart agent.
The view coordinator agent sends an 'open' event to the control
component of the new bar-chart agent.
The control component of the bar-chart agent first retrieves data
from the top-level PAC agent. The view coordinator agent mediates
between bottom and top-level agents. The data returned to the barchart
agent is saved in its abstraction component. Its control
component then calls the presentation component to display the
chart.
The presentation component creates a new window on the screen,
retrieves data from the abstraction component by requesting it
from the control component, and finally displays it within the new
window.
The user enters new data into a spreadsheet. The control
component of the spreadsheet agent forwards this data to the top-level
PAC agent.
The control component of the top-level PAC agent receives the data
and tells the top-level abstraction to change the data repository
accordingly. The abstraction component of the top-level agent asks
its control component to update all agents that depend on the new
data. The control component of the top-level PAC agent therefore
notifies the view coordinator agent.
The control component of the view coordinator agent forwards the
change notification to all view PAC agents it is responsible for
coordinating.
As in the previous scenario, all view PAC agents then update their
data and refresh the image they display.
The user wants to read stored objects. The request is forwarded to
the read () procedure of the persistence component, together with
the name of the data file in which the objects are stored.
Procedure read () opens the data file and calls an internal
Readobject() procedure which reads the first type identifier.
Procedure readObject () calls the metaobject that is responsible
for the creation of objects. The 'object creator' metaobject
instantiates an 'empty' object of the previously-determined type. It
returns a handle to this object and a handle to the corresponding
run-time type information (RTTI) metaobject.
Procedure readobject () requests an iterator over the data members
of the object to be read from its corresponding metaobject. The
procedure iterates over the data members of the object.
Procedure readobject ( ) reads the type identifier for the next data
member. If the type identifier denotes a built-in type--a case we do
not illustrate--the readobject ( ) procedure directly assigns the
next data item from the file to the data member, based on the data
member's size and offset within the object. Otherwise
readobject () is called recursively. This recursion starts with the
creation of an 'empty' object if the data member is a pointer. If not,
the recursively called readobject ( ) operates on the existing layout
of the object that contains the data member.
After reading the data, the read ( ) procedure closes the data file
and returns the new objects to the client that requested them.