Reputation: 5726
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.
Upvotes: 1
Views: 338
Reputation: 5726
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.
Upvotes: 0
Reputation: 198
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 e.g. at ecore's EOpposite feature in EReferences.
Upvotes: 1