Program Design

• Please read chapters 4 and 5 of the book.
  • Our book is not an OOP book, it is more of an advanced C++ book.
  • His views on design are good, but there will be others with different, more intense views.
  • These chapters have good information, some of which is more related to project than oop.
  • But I think it is important that you read them.
  • If you want a leg up, read chapter 28 as well.
  • You will go into much more detail when you get to software engineering.
• You can read 146-158 (The sections on reuse) lightly.
• The first part of chapter 4 he introduces us to design and the importance of design.
  • Why is program design important?
  • Why would it be more important as you progress in as a programmer?
  • I know some of you post-design your programs.
  • Read paragraph 1 on page 139.
• He discusses functional and non-functional requirements
  • Functional requirements describe what the code has to do, but not how it does it.
  • Non-functional requirements describe a condition of the project
    • It must be secure
    • It must be easy to use
    • It must compile on a given set of hardware ...
• He states
  • Some companies
    • Functional analysts write the functional requirements
    • Software engineers/architects create the design
    • Developers/programmers implement the design.
  • In others, developers do all three
  • And all mixes in between.
• Last semester, I hope you saw how a good design can lead to generic functions that reduce coding.
• We will see the same thing this semester with data structures.
  • He introduces this on page 140 with the example of chess pieces
    • Should I have a ChessPieceT? A class that represents any chess piece.
    • Or should I have a PawnT, BishopT, ...?
    • They have common properties and methods
      • color, location, Move, Draw, Promote
    • But won't the Draw and Move functions be different?
  • We can solve this problem with a hierarchy
    • A base class provides a common interface and common methods and properties
    • A derived class provides additional methods/properties and overrides existing methods.
    • A PawnT is a ChessPieceT
• Read the box on page 142.
• Before we get too far, what is the difference between functional decomposition and object oriented design?
• Abstraction
  • Booch et al

    • An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

    • He quotes a reference

      ... a simplified description or specification of a system that emphasizes some of the systems details or properties while suppressing others. A good abstraction is on that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment, immaterial or diversionary

  • Gregorie gives the example of a television.
    • On page 142. Read and understand this.
  • What is a Fighter?
    • Think of the guy standing around in a medieval village with a sword.
    • Think of your ideal of a fighter in a book like Lord of the Rings or Beowulf.
    • Note that this has been abstracted in games like Pathfinder or D & D.
    • Or even further in games like Skyrim or Nethack
  • Why do we do this?
    • We have a limited capacity to track details.
    • Abstraction eases this.
  • Abstraction separates the external view from the internal actions.
  • This is sometimes called the abstraction barrier
  • Booch mentions two principles
    • The principle of least commitment where an object has an interface that provides the essential behavior of an object and nothing more.
    • The principle of least astonishment where an abstraction captures the entire behavior of an object, nothing more and nothing less.
      • There are no changes that go beyond the scope of the object.
  • Notice the "crispness" here
    • Objects should have clearly defined behaviors that are associated with the object
    • This changes depending on the level of abstraction.
    • What is a map?
      • Should it track the characters moving about on it?
      • Should it be able to draw it's self?
      • The answers to these two questions depend on the properties assigned to a map.
  • Abstraction is very difficult, but we are lucky this semester.
    • The game I want to work on has already abstracted dungeon adventuring
    • We just need to recognize this and use it.
• Gregorie suggests two possible approaches to a chess board

  • ChessPiece chessBoard[8][8]{};
    ...
    chessBoard[0][0] = rook;
             

  • Actually he deals with pointers, but we don't do that yet.

  • class ChessBoardT{
        public:
             void SetPieceAt(size_t x, size_t y, ChessPieceT piece);
             ChessPieceT GetPieceAt(size_t a, size_t y) const;
             bool IsEmpty(size_t x, size_t y) const;
        private:
    } 

  • Again he uses pointers but ...
  • Which represents a better abstraction of a chess board according to the above definitions?
• When we design an abstraction for a widget, we need to ask "What are the operations that can be performed on that widget?"
• Booch says there are four elements in building Object Oriented software
  1. Abstraction
  2. Encapsulation
  3. Modularity
  4. Hierarchy
• You might be thinking, this is what we called encapsulation last semester.
  • Again Booch

    Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.

  • For OOP people encapsulation is both
    • Information hiding (public/private/ protected in c++)
    • And bundling the functions with the data
  • Both of these maintain the abstraction barrier so the user of an abstraction need not, and indeed can not, know the implementation, just the interface.
• Modularity
  • Partitioning a program into individual components
  • Right now this is header and implementation files in c++
  • But in C++20, there are first class modules.
  • But unfortunately our version of g++ does not support this.
• Hierarchy
  • This is an is a relationship.
  • But much more
  • It allows us to reuse code
  • Much more of this to come, but
    • A thing wondering about in a dungeon is an entity (I couldn't think of a better word)
      • it has hit points.
    • A character is a specialization of an entity.
      • It will interact via dialog with other characters
      • as an entity it has hit points.
    • A player character is a specialization of an character.
      • It will interact via dialog with other characters
      • as an entity it has hit points.
      • It is controlled by a player
  • Each of these have properties they inherit from their predecessor.
• We will study the implementation of these concepts in more detail.