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?
Coupling in OOP Contracts: Many simple values of few complex objects as arguments?
object oriented