Chapter 6: Structural Design

Transcription

1 Chapter 6: Structural Design Class Rela5onships Design alterna,ves for class use and reuse Composi5on Containment Inheritance Code Reuse Design Principles

2 Rela5onships: Containment aka Holds- A subobjects held, as in a container LiNle or no type dependency Composi5on aka Has- A subobjects part of class/type composi5on Essen5al component => type dependency Inheritance aka Is- a Class hierachy: Base (parent) and Derived (child) classes subtype alters or augments inherited behavior Built- in (sub)type checking

3 Cardinality: Structural Design Details How many subobjects? 1:1 for inheritance; 1- many for composi5on by design Variable for containment Ownership Child owns parent component: may NOT be released Composing object may stub out/replace subobject None, usually, for containment Life5me 1:1 for inheritance; variable by design for composi5on Associa5on Permanent for inheritance Possibly transient for composi5on Temporary for containment

4 Table 6.1 Rela5onship details: class to subordinate Relationship Association Cardinality Ownership Dependency Replacement Composition Stable Variable Transferable Yes Yes Containment Temporary Variable No No Not relevant Inheritance Permanent Fixed: 1-1 Implied Yes No

5 Rela5onships: Design Details Different designs yield different control and maintainability Cardinality, ownership, life5me and associa5on Indicate flexibility, stability, and/or extensibility Overhead gauged by these measures. For example: has- a rela5onship may provide varying cardinality is- a rela5onship cannot vary cardinality has- a may postpone subobject instan5a5on is- a cannot postpone parent instan5a5on

6 Example 6.1 Postponed Instan5a5on of SubObject class justintime { // need appropriate memory management details // Suppress or define: copy constructor and operator= bigdata* generator; public: }; justintime() { generator = 0; } void process() { if (!generator ) generator = new bigdata; generator.process(); }

7 Table 6.2 Design Effects of OO Rela5onships Relationship Internal Access External Access Overhead Has-A Public None Variable Avoidable (SubObject) Interface Suppressed May echo Holds-A Public None Minimal Not relevant None Control Replacement Defer instantiation Is-a Public Protected Public Unavoidable Support Extend Suppress None

8 Rela5onships: Type Dependency Implicit in inheritance hierarchies expecta5on that subtypes (descendants) may override inherited behavior to customize, augment, or vary base behavior. Polymorphism and use of heterogeneous collec5ons is common in designs employing type dependencies Also significant in has- a rela5onship applica5on programmer remains isolated from internal dependencies.

9 Table 6.3 Object to SubObject Details Accessibility Association Cardinality Ownership Private Temporary or Permanent Fixed by class design same for all objects Object External Echoed functionality Delayed instantiation Fixed at instantiation Stable for object lifetime Shared Full or Partial access Stable but Replaceable Variable within object lifetime Transferable

10 Has- A vs. Holds- a Has- a rela5onships imply type dependency class dependent on subobject for data and/or func5onality Constructor may instan5ate subobject Class methods may be defined to replace/reset subobject Holds- a rela5onships imply temporary associa5on No significant dependency on type held Type could be replaced Number of subobjects held could be zero, without impact Type independence, like that of a container, expected

11 Has- A vs. Is- a Has- a allows one to encapsulate and control subobjects design variability in cardinality, associa5on, life5me and ownership Interfaces may, but need not, be echoed. Is- a implies a strong type dependency Child object may stand in for parent object Polymorphism, and heterogeneous collec5ons, supported through inheritance and difficult to implement otherwise (see chapter 7) Is- a impera5ve to reuse func5onality common interface Extensibility promoted Overhead is fixed as is cardinality, ownership, life5me and associa5on...

12 Example 6.4 Inheritance in C#=> Child stands in for Parent Parent pobj; // Substitutability: // parent object (reference) can hold address of child object // Not symmetric: child reference cannot hold parent address // pobj: handle of type Parent => // Parent interface accessible; child interface not pobj = new Parent(); pobj.parentfn(); pobj = new Child1(); pobj.parentfn(); pobj = new Child2(); pobj.parentfn();

13 Inheritance : Language Differences Java and C# support only public inheritance do not allow direct suppression of inherited interface C++ offers public, protected and private inheritance only public inheritance typically used with protected inheritance, all inherited public func5onality is demoted to protected accessibility with private inheritance, all inherited public and protected func5onality is demoted to private accessibility => applica5on programmer has less accessibility via a derived object C++ allows class designers to directly suppress inherited func5onality to change accessibility of individual inherited class methods

14 Example 6.5 C++ Direct suppression of Inherited Func5onality class Child: public Parent { // fields private by default }; public: void parentfn() { // now private => suppressed } Parent Child pobj; cobj; pobj.parentfn(); cobj.parentfn(); // compilation error: not accessible

15 Example 6.6 C# Designated suppression of Inherited Func5onality public class Child: Parent { public void parentfn() { //NOP } } // application code Parent pobj = new Parent(); Child cobj = new Child(); pobj.parentfn(); // parent functionality cobj.parentfn(); // compiles & runs & does nothing

16 How to choose design? Soiware design is not a one size fits all approach. Different intents yield different designs. Code reuse most feasible with clearly structured design Inheritance supports Type extensibility Polymorphism Heterogeneous collec5ons (see chapter 7) Composi5on provides Internal control Flexibility and, possibly, reduced overhead Encapsula5on via composi5on or containment isolates unstable code and allows one to wrap interfaces

17 Inheritance Appropriate when subtype checking needed Client need not check for subtype Class designer need not check for subtype Subclass provides automa5c subtype check (via compiler) Automa5c type associa5on Class hierarchy sets up type extensibility New subtype added easily No cut&paste fixes Code not brinle: new subtype does not break code

18 Example 6.7 C++ Monolithic class for Icon Movement class Icon { float speed, glow, energy; int x, y; int subtype; //spinner, slider or hopper bool clockwise; // need for spinner bool expand; // need for spinner bool vertical; // need for slider int distance; // need for slider bool visible; // need for hopper int xcoord, ycoord; // need for hopper void spin(); void slide(); void hop(); public:

19 Example 6.7 C++ Monolithic class con5nued public: // constructor must set subtype: client must pass value Icon(unsigned value) { } subtype = value; // use enum for readability // and then use conditional to set associated fields // tedious subtype checking: subtype drives movement void move() { if (subtype == 1) spin(); } else if (subtype == 2) slide(); else hop(); // again,tedious subtype checking:subtype drives flair details void flair() { if (subtype == 1)

20 Example 6.8 Tedious Type expansion without Inheritance // ALL methods in Icon that check subtype must be altered // in order to add new subtype zigzag // ERROR PRONE software maintenance void Icon::move() { if (subtype == 1) spin(); } else if (subtype == 2) slide(); else if (subtype == 3) hop(); else zigzag(); // ALL methods in Icon that check subtype must be altered // in order to add new subtype zigzag => // flair() must also be altered since subtype drives details

21 Example 6.9 C++ Icon class hierarchy class Icon { protected: float speed, glow, energy; int x, y; public: Icon( ) { } void move() { } void flair() { } }; class Spinner: public Icon { protected: bool clockwise, expand; void spin(); public: }; Spinner( ):Icon( ) { } void move() { spin(); } void flair() { }

22 Example 6.9 Icon class hierarchy con5nued class Slider: public Icon { protected: bool vertical; int distance; void slide(); public: Slider( ):Icon( ){ } void move() { slide(); } }; class Hopper: public Icon { protected: bool visible; int xcoord, ycoord; void hop(); }; public: Hopper( ):Icon( ){ } void move() { hop(); }

23 Example 6.9 Icon class hierarchy con5nued // easy to add new subtype zigzag class zigzag: public Icon { protected: }; void zig(); void zag(); public: zigzag( ):Icon( ){ } void move() { zig(); zag(); }

24 Code Reuse via Inheritance Child classes automa5cally receive one parent (data) component Access to all public/protected parent func5onality via Composi5on Composing class automa5cally receives zero, one or more subobject Access to all public subobject func5onality => Code reuse alone does not mo5vate design

25 Rela5onship Design & Code Reuse Composi5on Type extension NOT essen5al Type extension unlikely to be used alongside original Interface may be suppressed Cardinality of subobject may vary Inheritance Type extension essen5al Type extension LIKELY to be used alongside original Interface may NOT be suppressed Cardinality fixed at one (parent) is acceptable/preferred

26 Composite Principle Use composi,on in preference to inheritance Formalizes prac55oners preference for composi5on But Why? Composi5on more flexible offers more control over internal design than inheritance But remember, composi5on does NOT provide Built- in subtype checking Polymorphism Support for heterogeneous collec5ons (see chapter 7) Type extensibility

27 Principle of Least Knowledge Every object assumes only the minimum possible about the structure and proper,es of other objects Promotes low coupling Applicable to both inheritance and composi5on rela5ons Class design NOT dependent on private implementa5on details of any other class Design iden5fies rela5onships consequen5al effects of rela5onships => Class 5ed only to interface of parent/composed subobject

28 Open Closed Principle (OCP) A class should be open for extension and closed for modifica,on Inheritance is an anrac5ve design op5on for class hierarchies with implicit subtype selec5on to vary func5onality Subs5tutability (see chapter 7) Heterogeneous collec5ons (see chapter 7) Type extensibility A good inheritance design adheres to OCP individual classes preserved type extensions are seamless OCP promotes soiware maintainability.