You sound almost exactly like me when I first started! And I
triumphed Delphi for its ability to lower itself down to procedural coding
and not having to truly understand how or why components did what they do
just to be able to use them. I saw this as the beginning of a trend toward
a programming model that relied entirely upon its own wealth of prefab
objects, and relationships between them that anyone with a computer could
use tinker toy style, ( I'm too old for legos! <g> ), to create anything
wanted. I didn't realize until later that practically speaking, it's
impossible to draw a line between how many different component pieces should
be provided to create say an editor, or simply supply the editor! I came to
realize that the value of programming lies in its ability to allow one to
create new and/or different applications, thus you have to limit the degree
of componentization or object interchangeability that you employ or all you
will get is what has already been built for you. Like building a Heathkit
Radio kit or a model airplane! As a child that kind of follow the dots and
paint by numbers creations can be quite fulfilling and may even be necessary
in order to sponsor a valid sense of ego and self-worth. But any adult
still finding enjoyment or value from doing such things is most likely a
very uncreative creature who is merely trying to keep his or her hands busy.
There's nothing wrong with procedural programming, ( I'll duck now
), and I'm very glad that Delphi allows one the freedom to move gracefully
between it, classes, and objects within the same program. Much of the time
it really comes down to a choice of style whether you write a simple method
or two, or write a class to handle the situation at hand, but I'll almost
guarantee you that the more experienced you become and the better you
understand the value of scope, access, protection, and reuse that OOP
provides, it will become much easier to use everyday as you won't have to
really think about it. You'll simply build a class in your head and start
writing it the same way you write methods now!
As to all those Foobar examples out there meant to show us how to
build objects and/or classes, I really don't find them to be very helpful
either...at least not for anything more than first learning the basics of
how they are constructed and the options you have available to you. What I
do when ever I am faced with a particular need in a program I'm writing, is
to ask myself a series of questions, answering them as I can as the solution
grows before me.
What is the result or solution I am trying to get?
What information/data is already available I can use toward getting the
result or solution?
What additional information/data must I access to get the result or
solution?
What information/data/objects must I create in order to get the result or
solution?
Is there an API, method, pre-built class, or component already available I
can use to get or help get the result or solution?
What trigger, event, or condition requires the result or solution?
How accessible must the result or solution be? And to what must it be
accessible?
I look at all this and begin to substitute the individual pieces I
need into types, objects, evaluations, events, and states, building up a
pattern by diagramming the relationships between them AND their
relationships to their surrounding environ. I use simple bubble diagrams
now but more and more I'm seeing the need to go a little further and perhaps
learn UML or invent a more definitive methodology.
Once all this has been ground up and homogenized on paper, I try to
take a high view of the whole thing to see what must go together and what I
might or should separate out. I guess you'd call it a type of refactoring.
And this depends a lot on what kind of result or solution I'm looking for.
Do I need to a simple bit of data output, or am I providing a means to
controlling or answering the needs of another class or object such as a
queue list. This is the point where I decide how to approach the
problem...with a method, a class, object creation, etc., and once I've made
that decision then I can worry about structure and how I scope it's own
internals.
It seems like a lot when you tear it down like this but in reality
you're probably doing all this and more already. You just don't think about
the individual pieces of the thought process that goes into your design.
HTH's
from Robert Meek dba Tangentals Design CCopyright 2006
"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: Friday, April 21, 2006 2:27 PM
To: Borland's Delphi Discussion List
Subject: Re: Delphi and Java
Thanks Robert, Scott, and Cosmin--as always--for your responses. I've
requested one of the books you mentioned, Robert, via inter-library loan
(and I'm still keeping my eyes out for the ones you mentioned last week,
Scott). I'll save your message, Cosmin, for occasional reference as I go
along. In many ways, I'm the kind of person you mentioned--the one who
wanted to drag-and-drop his way into programming. Still, there comes a point
where one is ready to move beyond event handlers with lots of code (or
procedures) for handling events. I'm at that point, and have always assumed
I needed to eventually learn the ins and outs of object oriented
programming.
Through the years I've found good references that tell me about OOP ideas
and how to set up basic classes and objects in Delphi. For reasons
unexplainable to me, people seem to like using animals and/or pet shops
quite frequently as examples :-) So, I know how to write a TAnimal class,
make TDog and TCat classes that inherit properties from TAnimal, etc.
The difficulties come when I try to apply the ideas to real world
situations. First, it seems like there's a lot of applications that are
simpler to write in a more procedural style, e.g., general utility or
office-like apps for individual users, like a text editor, mp3 player, or
file utility program. Second, even when trying to create something that
*does* fit well (even to me) within an object oriented viewpoint, it's hard
for me to figure out where best to place methods, and how to have objects
communicate with one another. For example, if one were writing an
application related to managing students registering for courses, it makes
sense to have Student objects and Course objects. When one registers,
though, these objects would need to communicate with each other. I would
have trouble deciding how to do that, while keeping classes/objects
"encapsulated," and deciding where to place a Register method--after all,
registration affects *both* the Student and the Course.
So, for now, I'm taking a look at Beginning Java Objects. Even though "Java"
is in the title--hence my previous question--much of the book is about the
general ideas, with little or no connection to Java itself. I think the book
devotes a lot of attention to the issue I just mentioned.
Again, I appreciate the responses and the reading suggestions. I'm not a
programmer (yet!), but I am an educator, and I know that the teaching
resources available today for Java (beginners) are definitely superior to
those available for Delphi (and probably most other languages, too). So, I'm
glad folks sent along a couple of the older resources for Delphi that they
thought were both useful and still up to date enough to be valuable.
Later -- 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
