1 / 20

Object Design & Design Patterns: Hardware/Software Platform Defined

This text discusses the implementation of custom objects, modification and reuse of objects, and the use of off-the-shelf components to optimize design in the context of hardware/software platforms. It also covers the analysis of nonfunctional requirements, dynamic modeling, and interface specification.

bolivar
Download Presentation

Object Design & Design Patterns: Hardware/Software Platform Defined

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related