Object Design & Design Patterns for Efficient Hardware/Software Platform Development

1. Object Design & Design Patterns Hardware / software platform defined  objects must now be implemented design custom objects modify, reuse objects use off the shelf components restructure, optimize design

2. Design process (figure 6-2): Nonfunctional requirements Analysis *: these include --use cases and scenarios --class (ER) diagrams --sequence diagrams --CRC cards --state diagrams * Dynamic model * Analysis object model System design Design goals— guide trade-offs We were here Subsystem decomposition— teams of developers Object design Object design model Now we’re here

3. Four basic activities, occurring CONCURRENTLY: Reuse: --off the shelf components, class libraries, basic data structures and services --Design patterns used for standardization --Custom wrappers may be needed Interface specification (API---application programmer interface): --may also identify additional objects for data transfer Restructuring: --simplify, increase reuse if possible Optimization: --mostly addresses performance issues

4. Reuse: Application objects—for this particular system Solution objects—more general, e.g., data storage, interfaces, etc. Off-the-shelf: IP (Intellectual Property) “off-the-shelf” components may be attractive to reduce development time, but they may cause problems for later implementations if they are discontinued or if they are modified by their owners

5. Simplification process: Inheritance: a powerful method for simplification Inheritance used properly supports later modifications well But inheritance must model a true taxonomy 4 types of inheritance: --Specialization: detected during development of a specialized class --generalization: common properties abstracted from several classes --specification—subtyping, supports code reuse --Implementation inheritance: for the sole purpose of reusing code; objects not conceptually related (e.g., example in chapter 8 of set implemented as a derived class of “hashtable”—hashtable elements contain keys which are NOT needed by set elements)

6. Specification inheritance: formal definition Strict inheritance (Liskov substitution principle): basically, a method written in terms of a superclass T must be able to use instances of any subclass of T without knowing these are instances of a subclass Implementation inheritance / delegation: --Delegation—an alternative to implementation inheritance --Implemented by sending a message to the delegate class --Leads to more robust code --Between implementation and delegation, it is not always clear which is the best choice

7. Another solution, design patterns: design pattern: available to solve recurring problems in coding. A design pattern has: --descriptive name --problem description --solution (classes and interfaces) --consequences (trade-offs and alternatives) Examples: Appendix A

8. Design Patterns: • References: • 1. Gamma, Helm, Johnson, and Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. • Deitel, Appendix Q. • Bruegge & Dutoit, Appendix A • useful for experienced oo programmers--”what worked well in the past” for common oo programming problems • many examples of design patterns can be found in the literature and on the web

9. Design Patterns (1.1) • Design patterns and alternatives: • Start from scratch: you are writing a novel piece of code • Use a library component: you have a library component which does the job • Use a design pattern: you need something not provided by a library component, but the basic functionality is very similar to a library component or to a frequently seen programming task • With design patterns, you get a “head start” on your coding and you should be able to spend less time debugging

10. Design Patterns (2) • 3 basic types of design patterns are usually defined: • creational--common methods for constructing objects • structural--common ways of resolving questions about interobject relationships • behavioral--common ways of dealing with object behavior that depends on context

11. Design Patterns (3) • Some common creational design patterns: • abstract factory--creates a set of related objects • builder--keeps details of data conversions, if different data types supported • factory method--defines interface for creating a method, rather than a specific method • prototype--gives prototypical instance for object creation • singleton--ensures that only one instance of class is created; provides global access point

12. Some common structural design patterns: • adapter--translates between interacting objects with incompatibilities • bridge--flexible method for implementing multiple instances of abstract class • composite--hierarchical grouping of different numbers of objects from varying classes • decorator--wrapper around original object, with additional dynamic features • façade--standard front end for a series of classes • flyweight--allows sharing to support many fine-grained objects efficiently • proxy--delays the instantiation of the class until the object is needed Design Patterns (4)

13. Some common behavioral design patterns: • chain of responsibility--give objects in a chain of objects a chance to handle a request • command--encapsulate request as parameterized object; allow undoable commands • interpreter--define a method for each rule in a given grammar • iterator--access elements of an aggregate object, keeping representation private • mediator--holds explicit object references for classes that would otherwise be highly coupled • memento--store an object state for checkpoints or rollbacks • observer--all instances will be notified of changes to the observed class • state--behavior of an object can depend on the state it is in • strategy--set of related algorithms for a certain problem • template method--details of the algorithm are left to subclasses • visitor--allow new operations to be defined on an object structure without changing classes on which they operate Design Patterns (5)

14. Design Patterns (6) • Example: Iterator—J. Cooper, (Behavioral Patterns) • move through a collection of objects (array, linked list, ….) without knowing detailed internal representation • may only return certain objects in the collection, based on a user-specified criterion

15. Design Patterns (7) Example: Iterator—what variables will you need? e.g.: First: itemtype Next: itemtype Current_item: itemtype Is_done: boolean

16. Design Patterns (8) • In Java: • Enumeration functions like Iterator • Built into: • Vector class • Hashtable class

17. Design Patterns (9) • Class design issues: • If another thread changes the data while Iterator is active what should happen? • How much access does Iterator need to internal data structures to do its job?

18. Design Patterns (7.5) Example: Adapter—wrap around legacy code (Bruegge & Dutoit, A.2): Client ClientInterface Request( ) LegacyClass ExistingRequest( ) Adapter Request( )

19. Design Patterns (9.5)

20. Templates / Generics: Another way to improve productivity “parameterized item” Example: if we are designing a processor, we might want to specify a register to hold n bits; We want to declare registers of different lengths, so we use a parameterized version, where the specific value of n can be substituted at compile time Similar to the concept of a macro, e.g. C++: template C++ / Java / C#: generics Reference: comparison of C++ templates and Java generics: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B Templates / Generics