Alan Colburn wrote: > 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.
I wouldn't expect FBookList to have any book-creation methods. Libraries don't create books. Publishing houses create books. Whether your model needs a TPublisher depends on other factors, so TBook's constructor might be all that's needed. > 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, Should it really? Why is that? > then the event handler in Form1 should probably do no > more than call a function in the object, something like > TLibrary.ShowAllTitles, right? That implies that a library knows what it means to "show" something, and that suggests that the library has some concept of a UI, which is exactly what you're trying to avoid, isn't it? > 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. I might make a method called FetchTitles, and as one of its parameters, it would receive a TStrings object. Now I can have the library fill whatever TStrings object I have, including TMemo.Lines, TListBox.Items, and whatever other TStrings descendants I can find. Since neither the library nor the book knows how to present itself in string form, another parameter to FetchTitles could be a function pointer that receives a TBook and returns a string. FetchTitles would call that once for each book in the list before adding it to the TStrings object. Another approach is to have the TLibrary provide an iterator object. Then I don't need any permanent storage outside the library. If I want to print a list of all the books, I can use the iterator to get one book at a time instead of getting my own copy of the list. I think a TDataSet provides that kind of interface. > 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? Whenever the caller is finished using it. As you presented the function, it is a TStringList factory. The way I presented the things above, the library never creates anything it doesn't own. > 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? I have no idea. How did you put them there? What owns the books? -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
