Outline the need to reduce dependencies between objects in a given problem.


Teaching Note:

Students should understand that dependencies increase maintenance overheads.


Sample Question:


JSR Notes:


First of all, by "dependencies" we are talking about when there are "connections", i.e. relationships between classes. So in the diagrams of the previous assessment statement, every time there is an arrow, either for a "is a", "has a", or "uses" relationship.


This is a curious one assessment statement because it seems to be counter to the whole idea of OOP programming. We actually want to divide up and have specialization with our various classes. This, by definition will create dependencies between objects. But, yes, we don't want to over-do it.

When it is easy to keep certain functionality within a certain class, and that class is not too big already, then, yes, go ahead and add to it. So, for example, it could be argued that our SortAndSearch classes could very well be left right in our MainGUI classes. And they could. But, personally, I would say the only thing that should be in the GUI is GUI stuff. And certainly the template classes have to be their own classes. So the way you would have done/will do your dossiers is probably just right.

Still, you can imagine that if you went wild with classes, making separate classes for every little thing, it would soon be a mess, and would be hard to keep track of what does what where. You may end up with classes dependent on classes, which are dependent on other classes, and so on. This would be hard to keep track of. Furthermore if/when another programmer comes to work on your program many years later, after you're long gone, it will be all the harder for them to makes sense of all your classes and dependencies.

One other reason to keep dependencies to a reasonable number is if the "connection" between them gets broken, it can screw up the whole program. And keeping the connections working correctly takes extra attention since you are working with different classes, not within the same class/code. An easy example to appreciate this is when you change the constructor of one class, you need to change all of the instances of calling that constructor in other classes which use it. This is the "maintenance overhead" mentioned in the Teaching Note.


Summary of Reasons to Keep Dependencies a Reasonable Number:

- potentially makes the program harder to follow, more messy, with so many classes

- more interactions/communications between classes that could potentially be broken

- more maintenance overhead, in that changes to one class demand changes to another/other classes