Re: Haven't done anything real with OOP yet.
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/27/04
- Next message: Ilja Preuß: "Re: Simple UML question"
- Previous message: Ilja Preuß: "Re: Simple UML question"
- In reply to: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Next in thread: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Reply: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 27 Oct 2004 20:05:23 GMT
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.
>>...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.
OO is also very good at extracting the invariants of paradigms. That's
why one sees a lot of GUI examples. Once one recognizes basic
abstractions like Window and Control, one can write a subsystem for GUI
display that is quite generic and reusable across applications. But
when one does that one needs to narrowly limit the subject matter to GUI
display. That's why in my solution I postulated 2-3 distinct subsystems.
So long as one is dealing only with the GUI designer's view of the UI,
it is pretty easy to abstract for vanilla UIs. However, the
manipulations for an active graphics panel are a different issue. The
sophisticated algorithms for shading, 3D, coordinating multiple Sprites,
and whatnot are highly algorithmic. While one can abstract that in
terms of objects one will tend to end up with relatively few classes
that have mongo methods that, in turn, invoke a large function library.
In your example, though, that would not be the case because your heavy
duty algorithm is copy-bytes. (It would also be pretty trivial, which
is why I suggested combining it with the GUI subsystem.)
My real concern in this context was about the temptation to overlay
procedural paradigms onto the OOPL code because of the algorithmic
nature. That's way I don't think it is a good place to try to learn OO,
at least without some significant mentoring -- even with a simple
example like yours. However, if you separate the semantics in
subsystems as I suggested, that problem will be largely mitigated
because the example is so simple. Once the concerns and subject matters
are partitioned, it is a lot easier to apply proper abstraction in
constructing classes.
>
> 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.
While Java is now the leading OO language in use (according to a recent
InfoWorld survey with a small sample), I agree with Gagne that there are
other OO languages that would be a better place to start. For example,
though Smalltalk uses procedural message passing just like the other
3GLs, it does a good job of hiding it in the syntax while in Java every
collaboration looks just like a traditional procedure invocation a la
FORTRAN.
>
> 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...
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
- Next message: Ilja Preuß: "Re: Simple UML question"
- Previous message: Ilja Preuß: "Re: Simple UML question"
- In reply to: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Next in thread: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Reply: Gregory L. Hansen: "Re: Haven't done anything real with OOP yet."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
