I'll probably get blasted by the gurus here, ( I'm used to it! <g>
), but you shouldn't think about OOP as an absolute! Like everything else
practical OOP has its place and I tend to follow its guidelines in 90% of
the applications I write. BUT, that doesn't mean it MUST be followed to the
nth degree everytime you code!
I'm a minimalist, and as such tend to consider solutions based upon
need and performance, not on method or style. And although the simple
application you describe below may indeed benefit from a class or two meant
to handle the basic input/output of your data, I probably wouldn't waste
much time on the separation of my GUI from process code or even get too
worried about splitting my classes into re-useable parts. The application
doesn't warrant spending that much time even thinking about such things!
In practice however you'll find that as you become more experienced
with OOP and class construction in general, you'll also begin to see that
your code naturally generates itself along OOP lines and that you won't have
need to think about it as much...just as you probably do now for procedural
code. And as you progress to this point you'll naturally develop your own
sense of what methods are best for which situations. Remember they were
writing computer programs long before the acronym "OOP" was first coined,
and they'll be writing them long after it has gone the way of the dinosaur!
from Robert Meek dba Tangentals Design CCopyright 2006
Proud to be a moderator of "The Delphi Lists" at elists.org
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Alan Colburn
Sent: Thursday, June 08, 2006 5:29 PM
To: Borland's Delphi Discussion List
Subject: Re: Learning OOP (part 4) [warning: moderately long]
Since traffic on the list has been light ... What I'd like to do now is to
take an application I wrote awhile ago and rewrite it, from the ground up,
in a more OOP-centric way. The original app is poorly coded, hard to
understand, and in need of a better GUI. I'm looking for a little assistance
in how to go about planning the app and its classes. Usually I just create a
GUI I like, and start making event handlers; it's time to become better
planned.
Description: Teachers sometimes grade student papers with the help of a
"rubric." Basically, imagine dividing your expectations for an assignment
into a list of specific criteria, and then rating a student for how s/he did
on each criteria. If you were teaching people Delphi, for example, you might
give students an assignment involving solving a problem with an array. One
of your performance criteria might be as simple as "You used an array in
your program," with choices of "yes" or "no." Or you might have something
like "Variable names were self-commenting, adding to code readability," with
criteria of "excellent," "good," "acceptable," or "not acceptable." Teachers
may optionally give students additional (text) feedback and, of course,
ultimately assign a grade. Students get a report about how they were rated
on each criteria, any additional comments, and their grade. ... I'll leave
out other details.
GUI: Upgrading from Delphi 5 to 2006 I saw the addition of the
ValueListEditor widget, and think that would be good for the rubric.
Performance criteria can go on the left column, and ratings can go on the
right column (with a pick list for each row). A memo or rich text box can
hold additional comments, and an edit box can hold the final assigned grade.
I picture the rubrics themselves stored as string lists, which can be almost
directly loaded into the ValueListEditor. Student reports will be saved in
other files.
Now, here's the thing ... the way all this is coupled, esp. the
ValueListEditor and its accompanying key/value text, it's hard for me to
think of this as something beyond Form1 with event handlers again. I can
practically load a string list directly into the ValueList Editor--it seems
like a "business" class method, for example, would just load a string list
from a file, and return the string list. And it's hard for me to think in
terms of real life objects here ... it seems like there's just the rubric
and the person doing the grading. But I continue to hear about--and see for
myself!--the advantages of breaking an app into separate classes. Heaven
knows, my original app is like a house that was built without a blueprint;
it's hard to understand and inefficiently coded.
So, how would you think about dividing this app into multiple classes?
Thanks, as always -- Al
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
