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?
5
I think you may be confusing objects in a programming language with tuples in a database. You don’t have object inheritance in a database, unless it’s an object-oriented database. While you can simulate inheritance in a table-oriented database, it’s usually not thought of in that way. When it is, we designate it a 1:1 relationship, where Recruiter is the main table, and AdvancedRecruiter (or something similar) is the linked table with the additional information that belongs to the descendant object.
The thing you have to ask yourself when designing something like this in a database is the same thing that you would ask yourself when you’re designing an inheritance hierarchy in a programming language. The question is, is there some collection of data or behavior associated with some form of “enhanced” recruiter that does not belong in the main recruiter object, but is a natural subset of the main recruiter object? If you have that (which I suspect you don’t), then you have a candidate for inheritance. If you don’t have that, then just create a Recruiter table and put everything about a recruiter in there (except for lists of things, which are separate tables with a 1:many relationship to Recruiter).
What you’re calling “favor aggregation over inheritance” I have always heard called something else: “favor composition over inheritance.” What it means is that you should, whenever possible, compose objects; that is, combine them together in useful ways by having them talk to each other through their respective interfaces, or by having one object hold one or more references to another object; rather than having the objects inherit from each other. Composition favors more loosely coupled and more highly cohesive code. But again, none of this really has much to do with databases.
1
Tables primarily describe relationships, not neccessarily objects. Your design contains the following relationships:
Recruiter n:m Region
Region 1:n SubRegion
SubRegion 1:n Recruitment
… and each of these could be a table of its own. Instances of recruiters and regions etc. are referenced here by an ID. Given an object, it can look up attributes in the database by its ID:
I’m subregion 14. What are my recruitments?
SELECT Recruitment FROM SubRegion_Recruitment WHERE SubRegion = 14
Of course, you would abstract this through something like data access objects or similar.