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

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

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

4. 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 supplier Broker client

5. Problem: Iterating over a “Collection” of items array tree set

6. 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?

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

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

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

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

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

12. Iterator Design Pattern Structure > Iterator initialize( ) getCurrent( ) next( ) complete( ) > Collection concrete_Collectionconcrete_Iterator * 1 Note that we are using interfaces, and each collection of items may have more than one Iterator

13. Iterator Design Pattern Behavior Client concrete_Collection i = Iterator( ) concrete_Iterator create initialize( ) done= complete( ) loop [! Done] e = getCurrent( ) next( ) done = complete( ) X

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

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