More OO Design Background

• Some notes from Booch
  • He feels that the following are required for an object oriented approach
    1. Abstraction
    2. Encapsulation
    3. Modularity
    4. Hierarchy
  • Abstraction (Page 100 of your book, read it)
    • Booch quotes several people.
      • M. Shaw
        • "A simplified description, or specification, of a system that emphasizes some of the system's details or properties while suppressing others"
        • "A good abstraction is one that emphasizes details significant to the reader or user and suppresses details that are, at least at the moment, immaterial or diversionary"
      • Berzins
        • "a concept qualifies as an abstraction only if it can be described, understood, and analyzed independently of the mechanism that will eventually be used to realize it."
    • Booch gives the following definition
      • 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 prospective viewer.
    • Gregorie uses an example
      • Think of a TV.
        • We know about the interface (on/off, volume, channel, display, ...)
        • It might even have the ability to add components (dvd player, ...)
        • But we don't know how the thing works inside.
      • The interface and the implementation are separated.
    • I don't think this is anything different from the ADT
      • For any object, we provide an interface (member functions)
      • This interface must provide full manipulative capabilities for the object.
    • By the way, they refer to this interface as a "contract".
      • It will always be there.
      • It will work.
    • In chapter 5, (p 138) Gregorie discusses using abstraction in decreasing.
      • The interface is the way people use your code.
      • The implementation is the way your code works.
      • The two should not be mixed.
    • How do you decide on an interface
      • Access to all internal data should be through the interface.
        • Variables (ie the member data, properties, ...) are implementation dependent.
        • Build getters and setters (observers and transformers)
        • You should not provide direct access.
        • You should at least validate the data values.
    • Some thoughts on member functions (the public interface, the contract)
      • Who are you designing this class for?
        • Personal use?
        • Team use?
        • Public use?
      • As you go down the list your freedom decreases
        • Private use, it can be flexible, incomplete and changing
          • But don't be sloppy
          • You may want to use this again in the future.
          • And a bad interface means you probably can't
        • Public use, the interface needs to be complete and thorough and stable.
        • The contract becomes more formal as you move down.
    • Gregorie says that this is hard
      • Look at what others have done.
      • Study the professional libraries.
      • Critique interfaces you have used.
      • Respond to feedback and adjust your system.
  • Encapsulation/Information Hiding
    • Booch describes this as a complementary concept to abstraction.
    • This is hiding the details of implementation
      • The data and data structures
      • The algorithms and implementation of algorithms.
    • "No part of a complex system should depend on the internal details of any other part."
  • Modules
    • In some sense this can be boiled down to separate compilation units.
    • We want to create units that we can reuse
    • It looks like C++ is headed to a better system in C++20
    • I can't find a great link.
    • But This is a start.
    • No include files, perhaps no object files.
    • And templates, which we will be tackling later are cleaner.
  • Hierarchy
    • Booch says
      • Abstraction is a good thing, but in all except the most trivial applications, we may find many more different abstractions than we can comprehend at one time.
      • Encapsulation helps manage this complexity by hiding the inside view of our abstractions
      • Modularity helps also, by giving us a way to cluster logically related abstractions.
      • But still this is not enough. A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, we greatly simplify our understanding of the problem.
      • Hierarchy is a ranking or ordering of abstractions.
    • Take a look at The FLTK Toolket Widget documentation.
      • I a GUI system, a Widget is an abstraction of something that shows up on the screen.
        • In this case, the widget has all the properties and behaviors of something that you can put in a GUI.
        • look at size()
        • look at show.
      • The hierarchy gets a bit hard to look at without a knowledge of a GUI but
        • A box is a concrete item. It is just an rectangular item on the screen.
          • 
          • Notice the simplicity, as most functions come from a widget.
          • It derives most of it's properties and behaviors from the widget.
        • A Button is an abstract thing as well.