Hi, Robert, Al, and All,
I wonder which modelling domains are best analyzed in terms of
object-oriented analysis yielding object-oriented designs and implemented in
object-oriented programming languages, especially, Delphi? (Don't think me
off topic if I ask what domains was Simula67 designed to model and
simulate.) Specifically, which information modelling tasks lend themselves
most readily to (data-centric) object-oriented approaches with encapsulation
of data with exclusive access to setting and getting through methods
designed around a specific data set? I am aware of the utility of OO
approaches in discrete event modelling of lifts, toasters, thermostats,
automobiles, planes, and metabolisms, but are there clear examples in which
procedural/functional modelling/programming approaches would be highly
inefficient and artificial compared to object- or component- oriented
approaches?
Many thanks for a lively and useful thread,
Paule
----- Original Message -----
From: "Robert Meek" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Monday, June 12, 2006 2:40 PM
Subject: RE: Learning OOP (part 4) [warning: moderately long]
> 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
>
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
