Designing with Reuse

1. Designing with Reuse • Application reuse • Incorporating applications wholesale • Adapting existing applications to new domains • Component reuse • Different granularities. Current focus. • Function reuse • Code libraries since 60s. Designing with Reuse

2. Component ReuseBenefits • Increased reliability • Components exercised in working systems • Reduced process risk • Less uncertainty in development costs • Effective use of specialists • Programmer expertise encoded in reusable elements • Standards compliance • Embed standards in reusable components • Accelerated development • Avoid original development and hence speed-up production Designing with Reuse

3. Component ReuseAssumptions • It must be possible to find appropriate reusable components • The reuser of the component must be confident that the components will be reliable and will behave as specified • The components must be documented so that they can be understood and, where appropriate, modified Designing with Reuse

4. Component ReuseProblems • Risk of increased maintenance costs • Lack of tool support • Not-invented-here syndrome • Added task of maintaining a component library • Finding and adapting reusable components Designing with Reuse

5. Component ReuseProcess • Design system and then search for components • Outline system, search for components, use results to influence design Expense of tailoring design to existing components offset by lower development costs. Designing with Reuse

6. Component Reuse Maintenance and Evolution • Source code may be hard to change, or not available at all. • Additional costs offset by benefits? Designing with Reuse

7. Component Reuse Development Guidelines • Generalize existing components • Should reflect stable domain abstractions • Should hide state representation • Should be as independent of other components as possible • Should publish exceptions through the component interface Designing with Reuse

8. Component Reuse Development Guidelines • Tradeoff: Reusability vs. Usability • The more general the interface, the greater the reusability • The more general the interface, the greater the complexity, the less the usability Designing with Reuse

9. Code Generators • Encoding reusable knowledge in automatic code generators • Most successful examples: • Parser generators (lex+yacc/bison) • CASE tool code generators (UML  implementation/template) • Very useful, but domain-limited Designing with Reuse

10. Application Families • Application family (a.k.a. product line): related set of applications with common, domain-specific architecture • Common core reused during development of new specialized application Designing with Reuse

11. Application Families • Platform specialisation • For different hardware/OS platforms • Configuration specialisation • Different peripheral devices (e.g. types of visual displays) • Localization • Functional specialisation • Different versions of application for customers with different requirements Designing with Reuse

12. Design Patterns • Predefined abstract designs • Implementations written (“owned”) by developers • May leverage OO language features (inheritance, polymorphism) • Discovered by analyzing code bases Source: Gamma et. al. “Design Patterns: Elements of Reusable Object-oriented Software” Designing with Reuse

13. Design Patterns (example) FACTORY METHOD (a.k.a. VIRTUAL CONSTRUCTOR) DESCRIPTION: Lets a class defer instantiation to subclasses CONSEQUENCES: Eliminates need to bind application-specific classes into code. Superclass can choose from host of (subclass) implementations based on parameters at construction time. Designing with Reuse