3

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?

  • Are the full time and part time recruiters dramatically different, or is full time/part time merely an attribute of the recruiter? – Robert Harvey Oct 8 '13 at 21:00
  • Well, the part time recruiters are kind of like a more limited group of recruiters, but are almost always bound to a full time recruiter.Maybe I don't need that level of distinction though, and can simply make the recruiter object accomodate both of them. – Cowman Oct 9 '13 at 0:03
  • That would be my guess. – Robert Harvey Oct 9 '13 at 0:22
  • What is the point then to even make an abstraction of it in the first place? I keep seeing information along the lines of "make everything an abstraction"... but if I can't expect the nature of a "Recruiter" to change, why even make it an abstraction. Is it just future proofing, in case things do change, and I need to be able to seamlessly swap the new one over to whatever is depending on the Recruiter object? – Cowman Oct 9 '13 at 1:09
  • See my answer below. – Robert Harvey Oct 9 '13 at 1:43
1

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.

| improve this answer | |
  • Just as an aside, is it a bad thing to have objects composed of abstract objects in sort of hierarchy like I have? That just seems wrong to me for some reason... But I don't know why. Thank you very much for your answer by the way, it kind of clears things up for me! – Cowman Oct 9 '13 at 3:05
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.