----- Original Message -----
From: "Alan Colburn" <[EMAIL PROTECTED]>
To: "Borland's Delphi Discussion List" <[email protected]>
Sent: Friday, April 21, 2006 11:27 AM
Subject: Re: Delphi and Java
> 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.
One technique I often use in a custom class is to put a 'pointer' or
instance variable to another custom class:
eg.
tCourse = class(tcomponent)
public
CourseName: string;
//course specific variables/methods etc.
end;
tStudent = class(tcomponent)
public
Course : tcourse;
procedure Register(CourseName: string);
//student specific variables/methods etc.
end;
var Student: tStudent;
The Register method in tStudent could be used to assign the value of
CourseName
which may then be referenced as Student.Course.CourseName
An instance, Student, of tStudent has to create an instance of Course in its
constructor
(so that Course has assigned memory and is not NULL),
but then all the methods of tCourse are already available within the
tStudent
object;
It's possible to create hierarchies of components like this, each having
other
components nested internally;
Using procedural methods only (without objects), such structures
would be difficult to emulate;
> 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.
The basic ideas of OOP are pretty general;
> 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.
It's true that there is a lot of stuff on Java and its widely used,
but I have to say that I prefer to work in Delphi;
I am moving to Java/C# in order to have work,
not because I particularly want to;
(In Italy Delphi is not very widespread)
C# is also well constructed as far as OOP is concerned and is close to Java;
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
