Re: Haven't done anything real with OOP yet.
From: Gregory L. Hansen (glhansen_at_steel.ucs.indiana.edu)
Date: 10/27/04
- Next message: AndyW: "Re: XP Requirement Analysis?"
- Previous message: AndyW: "Re: XP Requirement Analysis?"
- In reply to: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Next in thread: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Reply: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 27 Oct 2004 20:44:38 +0000 (UTC)
In article <7cTfd.4252$uQ4.980@trndny08>,
H. S. Lahman <hsl@pathfindermda.com> wrote:
>Responding to Hansen...
>
>> 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.
>
>I agree the selecting a book is rather subjective, so my blog provides
>some criteria to use when browsing the local bookstore or library.
Well, I found one on data structures and algorithms in C++ (title is about
the same), a $90, used, for $30. It got good reviews on Amazon, I figured
it was worth risking the money. It's probably not quite design, but the
sort of thing I should have, anyway.
Also found a book on object oriented design in the library at work. Looks
like it starts with the specification, and goes through the design
process. It's about ten years old, but looks like just the sort of thing
I wanted.
>
>>>...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.
>
>OK, I may have overstated the case. Even hard-core scientific
>applications can be OO because there is usually a lot of peripheral
>stuff to be handled (UI, algorithm selection, initialization, DB access,
>etc.) besides the solution algorithms. OO can be very useful as "glue"
>for such applications. However, the core algorithms would probably be
>in realized code done with procedural or functional methods.
Speaking of hard-core scientific applications, I was thinking about the
simulation of a temperature controller. A few objects seem pretty obvious
to define; the plant, the thermometer and electronics that make up the
temperature measurement, the control loop, and the voltage output to the
heater resistor. But each of those are also a function that could be
defined. You could give the plant object an input heat and elapsed time
and receive a temperature, or you could give the plant function an input
heat and elapsed time and receive a temperature. Either I don't know my
programming philosophies as well as I thought I did, or there's very
little difference in this case, except using classes for one and functions
with static variables for the other.
>> 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.
>
>Sorry about it being confusing. If I can clarify anything specific...
Maybe I could follow along more easily if you type slower.
I appreciate your help, and any comments you might have, e.g. on the
temperature controller above. But for the most part, I think I just have
to read a little. And maybe find some different examples to work with.
Like a Zork-style adventure game. A "room" is an object, right? It would
certainly be well defined with a class, and each item the room contains
could also be described well with classes. But as with the temperature
controller above, I think now that just because something is a class
doesn't necessarily mean it's an object, or that the programming style is
necessarily OOP.
-- "'No user-serviceable parts inside.' I'll be the judge of that!"
- Next message: AndyW: "Re: XP Requirement Analysis?"
- Previous message: AndyW: "Re: XP Requirement Analysis?"
- In reply to: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Next in thread: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Reply: H. S. Lahman: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|