Re: Haven't done anything real with OOP yet.

From: Gregory L. Hansen (glhansen_at_steel.ucs.indiana.edu)
Date: 10/26/04

  • Next message: Daniel Parker: "Re: XP Requirement Analysis?" 
    Date: Tue, 26 Oct 2004 18:39:28 +0000 (UTC)

    In article <twvfd.882$CX4.371@trndny06>,
    H. S. Lahman <hsl@pathfindermda.com> wrote:
    >Responding to Hansen...
    >
    >> This looks like the place to ask. I understand the vague concepts of
    >> structured versus object-oriented programming, I know C and C++, and I've
    >> done a lot of small beer programming in Igor Pro for data analysis. Igor
    >> is a statistics package with a nice programming environment, but I found
    >> myself wishing for some more adult features like data hiding when I was
    >> putting together some things with graphical interfaces.
    >
    >Make sure you understand OOA and OOD before going much further. (For
    >some book recommendations, see the Books category of my blog.) Because
    >the OOPLS make compromises with hardware computational models, it
    >becomes fairly easy to transfer traditional procedural practices to an
    >OOPL where they actually become bad practices. So even if you plan on
    >using an OOP-based development process, you still need a good grasp of
    >OOA/D principles.

    I was hoping my little project would be a vehicle for OO study through
    practical application. When I look for software design books, I mostly
    find handbooks for specific applications, the web, My First Book on
    Programming type of books, and then there's the set that seem like
    they're intended for people with a lot more experience than I have and are
    priced at standard textbook levels. If it were a Dover book for $12.95 I
    could just buy it and take a chance, but I'm not as free with an $88
    textbook.

    >> But I haven't done anything real with OOP, and I wanted to start with a
    >> simplest non-trivial problem. I have a book on game programming for the
    >> Macintosh (pre-OS X, I have an old machine), and wanted to convert a
    >> sample C program to a object-oriented C++ program (as opposed to changing
    >> the name from HelloWorld.c to HelloWorld.cpp and recompiling).
    >
    >The word "convert" makes me nervous. Procedural and OO construction are
    >very different and the approaches are essentially incompatible.
    >Therefore any simplistic conversion is very likely to result in a bad OO
    >program (i.e., a C program with strong typing). The best way to
    >approach your project is to ignore the original example and build the OO
    >application from scratch. That is, the only thing in common are the
    >requirements. Then compare the results.

    The original also has some functions that manage sound and do other
    system-level things. But yes, I could just rename the file HelloWorld.cpp
    and compile it, but I didn't want to do that.

    >>
    >> The program starts with a clam standing on the beach. When the mouse
    >> button is pressed, the clam starts running left to right until the button
    >> is pressed again. Then the clam stops and says "Hello, world."
    >
    >This is too simple. You aren't solving any customer problem that
    >requires unique rules and policies. That's because...
    >
    >>
    >> Internally, the program has an on-screen window, and a number of
    >> off-screen windows-- one with a picture of the beach, one with all the
    >> sprites which are copied from appropriate small portions of the picture,
    >> one with masks that are black-and-white sillouettes that tell CopyBits()
    >> what to copy and what not to copy, and a work space where a new image is
    >> composed before copying onto the main screen for flicker-free animation.
    >>
    >> The animation is done by copying just the portion of the background
    >> covering the old and new clam positions into the working window, and the
    >> new sprite in the new location on top of the background, and then copying
    >> that portion on the main window.
    >
    >...the real problem here is a graphic engine. That is an entirely
    >different problem space from clams running along beaches. That is, the
    >semantics here is independent of the game (i.e., a Sprite can be a clam
    >or a B2 bomber). Game software is very state-of-the-art algorithmic
    >software, which is generally not a good application of OO development.
    >That's because the benefits of OO development lie in software
    >maintainability when requirements are volatile over time. Graphics
    >algorithms, though, are mathematically defined (i.e., they are not
    >unique to the specific customer problem (game)) so they are invariant
    >over time. About the only OO benefits one can obtain using OO
    >principles is large-scale modularity and reuse (i.e., at the subsystem
    >level).

    That's not really what I expected, since OOP seemed well suited to
    graphical interfaces where you might have a window with a bunch of
    controls to manipulate. I thought, in the case of a game, each object
    running around (a monster or whatever) would be ideally represented as an
    Object with its own properties and things that it can do.

    Another thought was to learn Java, since that's promoted as an ultimate
    OOPL and I think Java books get their readers to flashy graphical stuff as
    soon as possible. But I have an old Mac, it can't run OS X and Java 2
    isn't available for it, and I wasn't sure how much a typical introductory
    Java book would actually teach about OO anyway.

    I've read through your suggestion, and I think I found it confusing enough
    that maybe I should read a book before I go much farther.

    >
    >This example is simple enough so that one could come up with an OO
    >solution. However, I think it would be a poor vehicle for learning OO
    >because it will be very hard to avoid procedural mapping. IOW, the
    >algorithmic nature of the problem is more intuitive in a procedural
    >approach than in an OO approach, so it will be difficult to avoid
    >applying a lot of procedural baggage from your prior experience.
    >
    >Worse, when you were done the OO solution would probably look pretty
    >bloated compared to the original procedural solution, which isn't likely
    >to inspire a warm and fuzzy feeling about OO development. My point here
    >is that one can create an OO solution for a Quicksort algorithm that has
    >classes like Pivot and Partition, but it would be overkill compared to
    >procedural solution with one public function and a couple of small local
    >functions, all in a single .c file.
    >
    >>
    >> I'm having a little trouble figuring out the OOP logic of that. I see a
    >> window object and a clam object, but there's a number of interactions so
    >> it seems they're not so hierarchical, I think there'd have to be a lot of
    >> talking between the two. Does the window copy the clam, or does the clam
    >> copy itself to the window? Does the window tell the clam to take a step,
    >> or give up control entirely until the clam detects a mouse click? Does
    >> the window tell the clam when it ran off the screen, or tell the clam
    >> what the screen bounds are?
    >
    >Clams and Beaches are different abstractions from Windows and Controls.
    > In fact, there are entities in different problem spaces: game
    >semantics vs. GUI display semantics. (In your case you might have a
    >third problem space whose subject matter is graphic image manipulation
    >that should have a unique suite of abstractions like Sprite or Graphic
    >Element.)
    >
    >In an OO application one should separate these concerns by encapsulating
    >them in subsystems or layers. (There is also some advice on
    >partitioning the applications into subsystems in my blog.) That allows
    >one to provide abstractions that are tailored to that particular view.
    >Note that this already creates a problem for your exercise -- it will
    >probably seem silly to identify three entire subsystems for what the
    >procedural example probably did in a couple of .c files. That's because
    >the benefits of OO really only shine in larger applications; when one
    >applies good OO practice to small problems, one tends to go all bloaty.
    > So you are going to have to ignore that if you pursue this particular
    >problem.
    >
    >For this simple example I would be inclined to combined the GUI and
    >graphics manipulation in one subsystem since you aren't doing any fancy
    >ray-tracing for shadows and whatnot. Doing so will pollute the
    >semantics of the GUI subsystem slightly but you aren't planning to reuse
    >any of this in other applications (I assume). Then things might go
    >something like...
    >
    >The game semantics subsystem will be pretty trivial with Clam and Beach
    >classes. (Beach limits the Clam's walk.) When the GUI announces a
    >click the Clam starts walking. It periodically reports its new position
    >to the GUI subsystem. When the GUI reports the next click, Clam stops
    >walking and reports its final position to the GUI subsystem. The only
    >significant behaviors in the whole subsystem are figuring out what the
    >position is and turning around at the end of the Beach. Those behaviors
    >will all be in Clam; Beach is just a dumb data holder that specifies the
    >beach boundaries.
    >
    >The GUI is more interesting. The mouse clicks from the winproc (or
    >whatever Apple uses) message loop are just forwarded to the game
    >semantics subsystem. You will have to abstract the basic elements of
    >the GUI paradigm in terms of Window, Controls (e.g., the Quit I'm Bored
    >button), Graphics Pane (or whatever Apple uses), and Sprite in order to
    >talk properly to the OS window manager. The logic you describe above is
    >what happens when a message announcing a new position is received from
    >the game semantics.
    >
    >Basically your GUI subsystem needs to convert the position in the
    >message to a location in the Graphics Pane. That's probably a job for
    >the Sprite, which will probably know its current boundaries. When it
    >computes its new boundaries, it sends Graphics Pane a message. The
    >Graphics Pane does the dirty work with the buffer copy of the pixel data
    >it reads from Sprite.
    >
    >Caveat: this is just a skeleton and a speculative one at that. I have
    >left out key behaviors like initialization and you may want to model the
    >GUI differently depending on how you will actually access the OS display
    >facilities (e.g., direct buffer write vs. OpenGL or somesuch). Consider
    >it just a push in the right direction. 

    -- 
"Let us learn to dream, gentlemen, then perhaps we shall find the
truth... But let us beware of publishing our dreams before they have been
put to the proof by the waking understanding." -- Friedrich August Kekulé
  • Next message: Daniel Parker: "Re: XP Requirement Analysis?"