Chapter 6
Design Using C++

Kurt Nørmark
Department of Computer Science, Aalborg University


Abstract
Previous lecture
Index References Contents
The material in this short lecture touches on the stuff from chapter 23, 24, and 25 in the C++ Programming Language text book

Development and Design
Slide Annotated slide Contents Index
References 

Chapter 23 of The C++ Programming Language

  • Issues in this chapter

    • Phases in the development process, development methods, reusability, ...

  • Complexity

    • There is only one way to deal with complexity: divide and conquer

  • Think twice when introducing virtual functions

    • A class with even a single virtual function potentially acts as the interface to yet-to-be-defined classes

    • Making a function virtual critically affects the use of its class and the relationships between [...] other classes

Broad discussions on general and high-level issues in software development

Only few parts of this chapter are related to C++

Design and Programming
Slide Annotated slide Contents Index
References 

Chapter 24 of The C++ Programming Language

  • Issues in this chapter

    • Failing to take advantage of the programming language - five ways page 725

    • Class hierarchies, page 735

    • Containment relationships: Member of type X, type *X, or &X? Page 738-739.

  • Containment versus inheritance

    • It is not possible to derive from an unknown class

    • But a member of class can be polymorphic

  • Assertions, invariants, preconditions, postconditions

  • Fat interfaces

    • The union of interfaces to a broad set of related classes

    • A container, for instance

    • Fat interfaces are best avoided

Kind of Classes
Slide Annotated slide Contents Index
References 

Chapter 25 of The C++ Programming Language

  • Concrete types

    • Resembles built-in types

    • Do not take part in a class hierarchy

    • Provides run-time and space efficiency that makes them comparable to 'hand crafted' code

    • Similarities between concrete types are expoited by use of templates

    • Hide as much of the implementation as feasible without hurting performance

      • Use of inline functions helps a lot

    • Instances do not need allocation on the free store

  • Abstract types

    • Represents a single interface to a set of different implementations

    • Do not normally have constructors

    • Makes use of virtual functions, and virtual destructors as well

    • Instances (of subclasses) must be accessed via pointers or references

  • Node classes

    • Part of a class hierarchy

    • Relies on services from base classes

    • Adds new functions to the interfaces

    • Programming by difference/extension

    • Direct instances can exists - the class has one or more constructors

  • Action classes

    • An alternative to functions

    • An action can easily encapsulate 'its own data'

    • An instance of an action class is not 'fired' in the same way as a function is called

      • Can be seen as a delay

  • Interface classes

    • Adjust the interface of a class - similar to the Adapter design pattern

    • Handles name clashes when merging class hierarchies - multiple inheritance

    • Use of forwarding functions

      • For instance by redirecting a call to a virtual function

      • See pattern page 779

    • Wrappers for range check - page 781

  • Handle classes

    • A class small enough to allow value semantics - static allocation in a local variable

    • Encapsulates a pointer to the data representation proper

    • Example: The string class

Some observations from this chapter is similar to material normally covered by design pattern literature

Quotes
Slide Annotated slide Contents Index
References 

  • Every successful large system is a redesign of a somewhat smaller working system. I know of no exceptions to this rule

    • Page 709 on the use of models. In the broader context of 'The development process'

  • Maybe the most important criterion for a prototype is that it has to be so incomplete that it is obviously an experimental vehicle and cannot be turned into a product without a major redesign and reimplementation.

    • 711 on experimentation and prototyping

  • Most organizations reward individuals and groups that choose to re-invent the wheel

    • Page 714 on reusability

  • If productivity is measured in terms of number of lines of code produced, a sucessful application of reuse will appear to cause negative performance of programmers

    • 716-717, in a discussion on individuals and reusability

  • Some problems are best solved writing a set of procedures

    • Page 727, in the context of ignoring classes and 'design and programming language'

  • Forcing everything into a single hierarchy can introduce artificial similarities and obscure real ones

    • page 732, using class hierarchies exclusively. Class Object...

  • Naturally, a derived class depends on its base classes

    • It is less often appreciated that [...] if a class has a virtual function, the class depends on derived classes [as well].

    • Page 737 in the context of dependencies within a class hierarchy.

  • A one-to-one mapping between the design concepts and the programming language concepts should be used whereever possible

    • Page 747. As an example: delegatation.

  • A major concern of a class design is to get an object [of that class] into a well-defined state

    • The simple act of defining invariants and using them during debugging is an invaluable help in getting the code right

    • 748 - 750 in the context of invariants

 

Chapter 6: Design Using C++
Course home     Author home     About producing this web     Previous lecture (top)     Next lecture (top)     Previous lecture (bund)     Next lecture (bund)     
Generated: March 26, 2013, 13:03:55