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 toolkit2. 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

supplierBrokerclient

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. Information hiding: do not expose the internal structure of the collection

2. Multiple simultaneous iterations: capable of iterating over the same collection with multiple iterations at the same time.

3. Simple Interface: the interface to the collection must not be cluttered.

4. 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 isto have extrnal-control-separate-Iterator

Iterator Design Pattern Structure

<< interface>>Iterator

initialize( )getCurrent( )next( )complete( )

<< interface>>Collection

concrete_Collectionconcrete_Iterator* 1

Note that we are using interfaces, and each collection of items may have more than one Iterator

Iterator Design Pattern Behavior

Client concrete_Collection

i = Iterator( )

concrete_Iterator create

initialize( )

done= complete( )

loop [! Done] e = getCurrent( )

next( )

done = complete( )

X

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