So I'm reading a book on Design Patterns (Design Patterns Explained 2nd Edition), and all throughout the book it says to "favor aggregation over inheritance".
I'm trying to wrap my head around trying to design something, and I feel so stupid.
So conceptually, I have
Recruiters. I figured these recruiters can be an abstract class, because I have a couple different types of recruiters... full time and part time. The thing is, I want each recruiter to be able to have references to other recruiters because they might work together and need to share and combine information.
Each Recruiter would have one or more
Regions that they oversee, perhaps sharing it with other Recruiters. All the region is a conceptual aggregate of
SubRegions. The SubRegions define places that fall along certain geographical boundaries. These contain some numerical statistic information about recruitments for that SubRegion as a whole.
The Subregions consist of
Recruitments, which contains detailed information about particular recruiting events for a SubRegion. They also contain other statistical information that makes sense to be under Recruitments(because they're very specific to the Recruitment), but not under SubRegions. Every time some information from the recruitment is updated, it needs to create a new record of that transaction so I can keep a history of how the numbers are adjusting.
Now, I want all of these to be able to be stored in a database. I am very naive when it comes to database design and structuring, especially when it comes to dealing with abstract classes and interfaces which are new to me.
Everything in the database is going to be linked in some way, among different tables. Say, the Recruiters are going to be a table, and there is going to be a Region table, a SubRegion table, and a Recruitment table.
Where do I need to put the logic, and how do I put it, such that I can make sure I can save everything out to the database, keyed together nicely, but loosely coupled in the code?