Class diagram for a simple application

Question

Suppose we have 3 entities: Library, Section & Book.

A Library consists of several Sections . A Section has several Books .

A Book may belong to only 1 Section . And finally a Section may belong to only 1 Library .

The way I see it is that class Library aggregates a collection of Sections and class Section aggregates a collection of Books .

Now I'm required to upload all Books to a server. I build a class BookUploader that takes a Book object in its constructor. On the server I created a folder for each Library and inside each library I'll create a Section folder and put the Book in it.

The problem is since I passed a Book object to the BookUploader I have no idea what it's Section is. In addition I don't know which Section belongs to which Library.

So I thought I'll just pass the Library object to the BookUploader then loop all Section then loop all Books in each Section, but someone told me that now BookUploader depends on 3 classes to upload a Book which is a bad design.

He suggested the each Book object should hold it's Section and each Section should hold it's Library which is the total inverse of my original design.

Can anybody share his thoughts on which design is better and why?

Thanks in advance.

Answer 1

There's nothing wrong with defining aggregation as one end of a bi-directional association. (Look here or here for examples.)

If you're looking for implementation details, about that, look eg at ecore's EOpposite feature in EReferences.

Answer 2

After reading @Chad's comment I realized that the design itself needed some modifications to the entities in question. what was missing is a function in each child class that would return a reference to its parent.