Hi Allen,
I'd propose that having TLibrary return a stringlist might start to make
TLibrary make assumptions about the GUI. It's perfectly valid to do as you
suggest but I would think you're starting to blur the lines between the
Library and the GUI.
Normally when you have a object like TLibrary, which implements a collection
of items (books in this case), the collection should be exposed item an item
property and a count property. To make it more specific to your example, you
might have:
TLibrary = class
FBookList: TList;
property Count: Integer read Get_Count;
property Books[AIndex: Integer]: TBook read Get_Book;
end;
The GUI would then simply iterate over the collection do as it will with
each TBook object.
As I said earlier, You could provide an addition method:
function Get_BookNamesList: TStringList;
To return a stringlist containing the list of names. If you do this, its
generally expected that the caller will be responsible for freeing the
stringlist when he's done with it as in:
myLibrary: TLibrary;
slBookNames: TStringList;
...
myLibrary := TLibrary.Create(); <-- Assume c'tor loads books
from DB
slBookNames := myLibrary.Get_BookNamesList;
Free(myLibrary);
... <-- Do something with string list
Free(slBookNames);
Notice that I deliberately freed myLibrary before freeing the
stringlist;
The problem implementing the stringlist as I did in this simple
example is that it assumes there is a relationship between the order of the
strings returned in the stringlist and the order of the strings in the
collection. A couple of ways to get around this might be to have the Object
property of the stringlist contain a key corresponding to the associated
item. Additionally, you could modify the Books property as in:
property Books[AIndex: Variant]: TBook read Get_Book
Get_Book would check the type of the variant and if an integer, use it as a
ordinal index into the collection, and if its a string, assume its the book
title and then have Get_Book search the collection for the matching entry.
I throw this in because its important to understand and decide the possible
ways the collection could be used and implement accordingly.
Scott Kellish
----- Original Message -----
From: "Alan Colburn" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, May 20, 2006 4:15 PM
Subject: Learning OOP (cont'd)
>A few weeks ago I sent a post about learning OOP via a Java-based book, and
> a few of you were kind enough to respond. I'm happy to tell you that I've
> made a lot of progress; I understand the OOP mindset a lot better now.
> It's
> exciting, and I thank again those of you who responded.
>
> Now I've got the task of taking all the general things I've learned and
> figuring out how the work in Delphi. I'm struggling a bit with
> understanding
> collaboration among objects, and keeping the GUI object separate from the
> "Model" object(s). I haven't found many Delphi-specific resources to help
> me; I'm open to suggestions (esp. web-based tutorials). Most discussions
> are
> either too basic for me now ("the difference between a class and an
> object,"
> "the definition of inheritance," etc.) or too advanced (it's great to know
> that my questions are addressed by understanding things like the Operator
> and Listener design patterns, but I'm not there yet).
>
> Along with this general question, I'd like to ask one that's a little more
> specific. To make responses easier, suppose you had a TLibrary class whose
> only field is a list of TBook objects. TBook, in turn, contains only a
> string field for titles. TLibrary.Create makes fBookList, and and
> TLibrary.Destroy frees the list. Adding a book to fBookList involves
> either
> (a) a pre-existing TBook instance or (b) creating the instance as part of
> a
> method. ... So far so good.
>
> Now, suppose in the UI you want to generate a list of all the books in the
> library. Since all the data manipulation should take place in a TLibrary
> object, then the event handler in Form1 should probably do no more than
> call
> a function in the object, something like TLibrary.ShowAllTitles, right? If
> the event handler was going to list the books in something like a Memo,
> then
> it makes sense that ShowAllTitles should generate a TStringList. ... So
> far,
> still so good.
>
> My difficulties relate to whether or not I'd be creating memory leaks, and
> understanding what needs to be freed by whom. The TStringList object
> created
> in the last paragraph--when is it freed? Once the Memo (in Form1) has been
> filled, the TStringList is no longer needed. But you can't just free it at
> the end of ShowAllTitles (Form1's Memo needs the reference). And how about
> all those TBook instances referenced in TLibrary's fBookList? When are
> they
> freed? [It's probably inappropriate for this list, but these kinds of
> questions get me wondering why Delphi doesn't have garbage collection.]
>
> Hope this is clear. Thank you again; this list has been helpful.
>
> Alan C.
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>
----------------------------------------------------------------------------
----
> _______________________________________________
> Delphi mailing list -> [email protected]
> http://www.elists.org/mailman/listinfo/delphi
>
CONFIDENTIALITY NOTICE: The information in this message is confidential and
may be legally privileged. It is intended solely for the addressee. Access
to this message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, or distribution of this message, or any
action or omission taken by you in reliance on it, is prohibited and may be
unlawful. Please immediately contact the sender if you have received this
message in error and permanently delete this message and any attachments.
Thank you.
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
