Inheritance guidelines in C l l l Inherit

  • Slides: 6
Download presentation
Inheritance guidelines in C++ l l l Inherit from Abstract Base Classes (ABC) ä

Inheritance guidelines in C++ l l l Inherit from Abstract Base Classes (ABC) ä one pure virtual function needed (=0) ä must have virtual destructor implemented ä can have pure virtual destructor implemented, but normally needed Avoid protected data, but sometimes this isn’t possible ä data is private, subclasses have it, can’t access it ä keep protected data to a minimum Single inheritance, assume most functions are virtual ä multiple inheritance ok when using ABC, problem with data in super classes ä virtual: some overhead, but open/closed principle intact Duke CPS 108 3. 1

Designing hyperwag l Keep classes small and cohesive ä as simple as possible, but

Designing hyperwag l Keep classes small and cohesive ä as simple as possible, but no simpler ä member functions should also be small l Design for change ä specifications, requirements, design ä example: other formats for table design? l Design first, code second, but revisit design Know the language, but don’t let the language rule the design Get the classes right, concentrate on what not how l l Duke CPS 108 3. 2

One view of hyperwag Duke CPS 108 3. 3

One view of hyperwag Duke CPS 108 3. 3

Patterns: Abstract Factory l l l Abstract Factory/Factory aka “kit” ä system should be

Patterns: Abstract Factory l l l Abstract Factory/Factory aka “kit” ä system should be independent of how products created ä system should be configured with one of multiple products (or families of products, e. g. , Win 95, Motif) ä you want to provide a class library of products and reveal interfaces but not implementations Consequences ä factory encapsulates responsibility and process of creating objects, clients only see abstract interface. “Real names” hidden in factory ä supporting new products can be difficult depending on the situation (but see Prototype pattern) Often want only one factory accessible in a program Duke CPS 108 3. 4

Patterns: Singleton l l Singleton ä enforce exactly one instance of a class, accessible

Patterns: Singleton l l Singleton ä enforce exactly one instance of a class, accessible in a welldefined manner ä possible to extend via inheritance Consequences ä controlled access to single instance, e. g. , Foo * foo = Foo: : get. Instance(); no global variables ä no need to rely solely on class/static functions Implementation ä private constructor ä get. Instance (or other class/static functions, see hyperwag) ä l Duke CPS 108 3. 5

Patterns: Prototype l l Use a prototypical instance to clone new objects ä classes

Patterns: Prototype l l Use a prototypical instance to clone new objects ä classes used in a program can be specified/loaded at runtime ä avoid hierarchy of factories that parallels hierarcy of classes Abstract Prototype class implements clone() ä ä l how to copy? deep vs. shallow how to initialize clones in subclasses Managing Prototypes ä use a factory or a prototype manager with registered prototypes ä cloning can be tough (e. g. , circular references) Duke CPS 108 3. 6