Simple Class question regarding hierarchies or Parent Child relationships.

I'm not sure this is the correct forum but I would like to model a library of books and I'm stuck on a key concept of OOP.  The library would contain one or more book types like "fiction" or "reference".  The book types would contain one or more books like "Gone With the Wind" or "VB Classes in 21 Minutes" :)  Each book would contain one or more "pages".  I have created a class for each object seperately but how do I model the fact that a book contains pages, a type contains books which contain pages, and a library contains types which contain books which contain pages   At first I created a parent container (ArrayList) for each class that contained the child objects but that seems akward at best.   I looked up "nested classes" but that caused my eyes to glaze slightly as I'm a novice programmer.  I would like to reference an object like:

DallasLib.Fiction.Gone With the Wind.Page(201).Display

or

DallasLib.Fiction.Gone With the Wind.Print

or DallasLib.Fiction.CountBooks etc. etc....

How do I model a class that contain objects of a child class   The main class that gets the most action is the Book class but I'm not sure that matters on this question.

DeBug

Yes, I will have to maintain the content of each page such as page number along with specific methods like view, print, and such. Also, I only need to work with a single book at a time with all the pages loaded in the pages collection. For example, to display a page, I would use the user input to search from the top level down starting with a single library, then the load and search all the types, followed by loading and searching for the book name. Finally, once that is located, I would load all the pages of that book (to a listbox) to allow the user to browse, view, print etc. The physical container for the objects are just a file share on a server and the library, types, and book names are folders. The pages are JPG file. I'm still confused on how to link the following classes using your collection example:

Public Class Book

public Title As String

public FilePath As String

' Like this public Pages() as Collection

End Class

Public Class Chapter

public Title As String

public StartPageNumber As String

End Class

Public Class Page

public PageNum as String

public FilePath as String

End Class

DeBug

Hi Doug,

There are many ways you can apply identification of potential classes. One of the most typical methods is to identify any nouns within the statement which represents your problem domain and then identify operations from the verbs/relationships. You have completed that within the scope of the library application, but as previously pointed out, there's some overlap with attributes and classes. However, it can be simplified. Lets take your example and write a problem statement (forgive me if this is not quite as intended):

Each library contains a number of books, these are classified by type (i.e. Fiction, Non fiction, etc.). Each Book contains a number of pages and a number of chapters. Each chapter starts on a particular page, and each page has a number.

So, from this there are some clear potential classes: library, book, type, page, chapter, number.

Some of these may be complex (classes) some may be basic (attributes/types). Candidates for simple types could be : type, number. We can see that book contains the type attribute, and page contains the number attribute. All other items would be classes. Note theres no fixed rule here, number and type could also be classes. Then we should aim to identify the relationships between the classes. Aggregation can be found by the use of 'contains', 'has' or similar, inheritence can be identified by 'is a'. As mentioned there are no hard and fast rules, these are just pointers. For example, the chapter has a start page, but this clearly indicated using these rules.

You could also have the type t as a class in its own right. Library could contain many types with each type containing a reference collection of books. As you can see, there are many ways to solve the same problem.

Anyway, this should then give you the basics of the static domain class model, which can then be enriched. As for the aggregation/composition types, its really driven by your intended method of access. Lists are very quick but only have integer indexing, whilst maps offer fast keyed access.

I could waffle on for a while, but I'm hoping this will give you a bit of help......

Thank you for a very thoughtful post.  I read up a bit on the dot net 2.0 collections class and only need to put my mind around boxing, unboxing, type safe, and other trade offs to choose which aggregation class to use.  That being just a performance vs. ease of use now I can focus on the objects.  I think I understand the objects themselves and have roughed in the following classes: page, book, and type.  The library itself would not need to be aggregated as each application instance only act on its own books.  I'm sure I can create the functionality I need using that.  The part I find most confusing is all the overlapping functionality and where to draw the line between business objects (classes) and the rest of the program.  For example, a listbox is being used to contain the pages in a book so do I really need add all the pages to an array and then bind the array to the listbox   The listbox itself provides that same collection functionality.  I hung on to VB6 way too long....

Thanks again for your reply!

DeBug

Decoupling presentation from logic is a common problem and which can be sovled using a pattern called Model View Controller http://en.wikipedia.org/wiki/Model-view-controller (or something similar). You can also enrich this pattern by adding a model to the view. This allows you to decouple view behaviuor from the presentation specifics (if you have presentation libraries in different technologies Java, .NET, etc.).

Wherever possible you should try to get into the habit of decoupling your business logic from your presentation, it makes it much easier to refactor (which is inevitable) later on.

Good luck.