Design Reuse
• Earlier we have covered the re-usable Architectural
Styles as design patterns for High-Level Design.
• At mid-level and low-level, design patterns are also
employed for re-use of solutions to recurring
problems. But there are other competing concepts:
– Toolkit : libraries of predefined and reusable Classes
provided by vendors with the language compiler.
– Framework: a set of cooperating Classes that make up a
reusable design for a specific application domain, which is
also provided by software vendors
Toolkits and Frameworks
• Toolkits are libraries of Classes:
– Each class is at the code level - - - “code re-use”
– Each Class is “independent” of another Class
– Each Class may be used more universally across different
domains
– Not really appropriate for mid-level design reuse, but more
appropriate for very low-level design re-use.
• Framework is a set of “cooperating” Classes:
– Dictates a design and the over-all structure of your solution
– It captures the design decisions common to an application domain
and is for “design re-use”
– Different framework may be needed for different application
domain
– A user of frameworks reuse the design, and focuses on the details
of the specific application
1. When using toolkit, one design the main body of the application and employ (re-use)
the specific Classes in the toolkit
2. When using a framework, one employ (re-use) the main body of the application and
code the specifics
Mid-Level Design Patterns
• Mid-level design patterns are:
– More abstract than framework or toolkit in that only
“examples of code” may be provided in patterns
– Smaller design element than framework
– Less domain specific than framework
– Sometimes “implemented” in current language such as Java
standard Class library
• There are many mid-level design patterns and
different ways to classify them:
– (Gamma, et al) by purpose:
• Creational: deals with the problem of object creation
• Structural: deals with composition of Classes
• Behavioral: deals with Class and object interactions and
distribution of responsibilities
– (Fox) by form and problems they solve:
• Broker: mediates between the client and the supplier of services
• Generator: provides instances of Classes to the client
• Reactor: provides solutions to event driven problems
Example of Broker Pattern
• A Broker pattern mediates between the client and the
supplier classes.
– A Client requests a Supplier service from the Broker, which
will interact with the Supplier to obtain the service on behalf
of the Client
• We will consider an Iterator Pattern in detail
client
Broker
supplier
Problem: Iterating over a “Collection” of items
array
tree
set
Seems Simple - - • What’s wrong with using the “for --- loop”
construct which exist in most programming
language?
• Nothing - - - but can it work for all types of
“Collections?” - - - - are there structures that
would be difficult to deal with?
• Should the iterator design be influenced by
the collection’s structure?
Some Desirable General Characteristics
1.
2.
3.
4.
Information hiding: do not expose the internal
structure of the collection
Multiple simultaneous iterations: capable of
iterating over the same collection with multiple
iterations at the same time.
Simple Interface: the interface to the collection must
not be cluttered.
Flexibility: there must be flexibility in processing
during the iteration processing (e.g. tolerate
changes to the collection while iterating through the
collection)
Where do we start in designing this?
• What’s needed to iterate through a collection?
– Initialize: prepare to start iterating and accessing the elements
of the collection
– Access: provide access to the “current” element in the
collection
– Advance: move to the “next” element in the collection
– Completion Test: indicate if all the elements in the collection
have been visited.
• Are there any other concerns?
– Revert: go back to the previous element
– Skip: visit only those that has certain characteristics
Design Choices
• Control:
– External: the client controls the iteration mechanism and the
iteration mechanism provides the elements from the
collection to the client, as directed by the client.
– Internal: the iteration mechanism accepts operations from
the client and applies to the elements of the collection with
out the client control over the iteration mechanism
• Residence:
– Within the Collection: the collection includes the iteration
mechanism
– Separate Iterator: a separate Iterator houses the iteration
mechanism
Built with-in the Collection
• Internal Control:
– Can easily hide the collection structure since the iterator
mechanism is part of the collection - - - - BUT
– Can not easily perform simultaneous iterations because the each
individual iterator can not be easily separated out .
– Lacks flexibility such as stopping the iteration half way because
there is no client control
• External Control:
– Can easily hide the collection structure by only exposing the
control interface ( initialize, access, etc.)
– Can be flexible by adding more iteration control functions - - BUT
– But the Collection interface may be complex as more iteration
control functions are added
– Can not support multiple simultaneous iterations because we can
not provide such an interface
Putting the iteration mechanism, with internal or external control,
within the Collection is NOT a good idea because some of the “desirable”
characteristics can not be met.
Build in Separate Iterators
• If the iteration mechanism is placed in a separate
Iterator, two of the previous problems are solved:
– Multiple simultanous iterations may be implemented by
using separate iterators
– Collection interface will remain simple even if more
functionalities are placed into the iterator - - - absorbs the
complexity
• The iterator must ensure that the internals of the
collection is not exposed to anyone but only to the
iterator itself.
• Iterator with internal control has the drawback of not
being flexible (in terms of client demands for altering
iteration)
Thus, the “best” choice for a general design for iteration mechanism is
to have extrnal-control-separate-Iterator
Iterator Design Pattern Structure
<< interface>>
Iterator
<< interface>>
Collection
initialize( )
getCurrent( )
next( )
complete( )
concrete_Iterator
*
1
concrete_Collection
Note that we are using interfaces, and each collection of items may have more
than one Iterator
Iterator Design Pattern Behavior
concrete_Collection
Client
i = Iterator( )
concrete_Iterator
initialize( )
done= complete( )
loop
[! Done]
e = getCurrent( )
next( )
done = complete( )
X
create
Implementation Considerations
• Some language may already have implemented the
Iterator - - - e.g. JAVA has an Iterator interface
defined as part of the class library for iterating
through a Collection of objects, one object at a time.
• If one is to implement the Iterator pattern, make sure
that the Collection’s internal structure is not
exposed.
– One way is to include the Iterator Class as an inner Class of
the Collection Class
– The crucial attributes of the Collection may be passed to the
Iterator via reference or via alias, allowing the Iterator to
access the internals of the Collection.
Pattern Description
• A pattern has 4 essential elements:
– Pattern Name : the short name
– Problem Description: Iteration mechanism for
arbitrary Collection of items
– The Solution: the various choices and the final
selection of the solution
– Consequences: trade-offs of applying the pattern
and possible implementation considerations