Coupling in OOP Contracts: Many simple values of few complex objects as arguments?

Question

When designing an OOP-based application, should one prefer to transfer information between objects through complex objects that do a lot of handling work, or should I retrieve the data from the holding object first, and hand over many arguments in the call?

Take, for example, an application that does timeseries econometrics and needs to transfer a list of dates as available in the data set. Using the first approach, I'd hand over a handle to the entire dataset-object, which in turn contains a calendar-object, which contains date-objects. All these objects handle different parts of the date-functionality, holiday checks, etc. Within the receiving object, the call would somewhat look like this:

xlDate = MyDataset.MyCalendar.MyDate.convertToXlsFormat()

While, obviously, that would happen before in the other case, and xlDate would simply be an argument.

Now I see that in general, tight coupling is bad, and this seems a little tight. I do, however, write scientific software, thus my users are always programmers who usually extend the program. For them, having all the handles available means less change, and less to worry about.

Think about a situation where you'd need yesterdays stockprices instead of todays. In the first situation, a programmer could very easily adapt the original function and replace it (since you can store functions in variables in Matlab, that can be done from a config file), while in the second, he'd need to add a control flow to the calling function, and thus increase the 'scope of responsibility', if you want to call it that, so the programmer needs a larger mental model of his specific function.

I thought of a wrapper as well, but I think that is just the worst of both: huge object handed to the wrapper, and your original function extends to the wrapper as well. I dont see benefits here.

So: How big is too big, and how deep nesting is too deep?

Answer 1

Some would say that even calling the method of another object is too deep. In your case, you shouldn't need to venture farther than MyDataset for all that you need in that method. The fact that you do need to move farther is an indication that your method is stretching beyond the reach of what it should be allowed to do and minimize coupling.

If you are using MyDataset only to get MyCalendar, the fix should be fairly obvious: remove unnecessary dependence to MyDataset and simply pass MyCalendar instance instead.

However, your class may even need an instance of MyDataset and MyCalendar. That doesn't mean that you should be calling MyDataset.MyCalendar. To fix this, you could do one of several things:

• Move required functionality of MyCalendar into MyDataset (not recommended if it doesn't make sense, and in this case it most certainly does not)
• Create a function in MyDataset that calls performs that functionality for you (facade pattern) (not recommended either for the same reasons as above).
• Make MyCalendar instance be passed into the method (recommended, only if you need MyCalendar for that particular function).
• Make MyCalendar instance be passed into constructor, in other words a class field (recommended, only if MyCalendar is used throughout your class). To ease this with your code, you could provide an alternative constructor without MyCalendar instance passed, which assigns your field value of MyCalendar from the instance of MyDataset passed.

If you require a date be in a certain format, I encourage you to resist the urge to format it within your function. This is for two important reasons:

1. Your function should not be doing anything other than what it is expected to do. If it needs a date in a certain format, it should already be an argument in the proper format passed to your function. It moves work outside of your function and simplifies it.
2. In this way you are modularizing your code as well as simplifying it. The converter can be in its own class. The end effect is the opposite of coupling. You are removing code, however trivial, that doesn't pertain to what that class is supposed to do and thereby eliminating duplicated code and keeping it easy to maintain.

It seems clear to me that you know that coupling is wrong, but I just wanted to point out some ways I try to approach the problem and hopefully I gave you a couple of ways to reduce and even eliminate coupling in your code.