CODEWITHSUNDEEP
c#oop
ford
ford

Reputation: 1887

Is passing an entire object or passing a series of parameters more maintainable in the long run?

I am passing data to Pages in C# by including a reference to an object as a parameter in the page's constructor. I'm only using a portion of the members of the object in the page. A call to such a page looks like so:

new PageName(DataObject);

Where the DataObject set to be the DataContext of the new Page:

this.DataContext = DataObject;

From which I can perform all data operations I need to do on DataObject. One key feature with this setup is that changes made to the DataContext affect the passed DataObject; this is intended and desirable.

This is fairly simple and works well for now. One concern i have is that PageName must know to cast DataContext to the correct object type, and must know the names of object properties, creating significant coupling. Is this generally an acceptable level of coupling, or would it be worth the effort to pass ref parameters to reduce the magnitude of coupling between PageName and DataObject?

Edit: On average, if I were passing parameters, I would usually need to pass 4-5 parameters to each page. Not every page needs the same parameters passed to it.

Upvotes: 2

Views: 1851

Answers (3)

Patrick Pitre
Patrick Pitre

Reputation: 851

From the venerable Code Complete (Steve McConnell), Ch. 7:

If you find yourself consistently passing more than a few arguments, the coupling among your routines is too tight. Design the routine or group of routines to reduce the coupling. If you are passing the same data to many different routines, group the routines into a class and treat the frequently used data as class data.

The upper limit for an understandable number of parameters is about 7...

And from Ch. 13:

Careful programmers avoid bundling data any more than is logically necessary. Furthermore, careful programmers avoid passing a structure as a parameter when only one or two fields from the structure are needed—they pass the specific fields needed instead. This is an aspect of information hiding: some information is hidden in routines, and some is hidden from routines. Information is passed around on a need-to-know basis.

Upvotes: 4

Jason Williams
Jason Williams

Reputation: 57892

If your page is not expected to change much, then the data it will consume will be relatively fixed, in which case you get a number of benefits of passing several specific values:

  • Decoupling - the caller is responsible for finding the data for you
  • No need to cast anything or have knowledge of the external data structures
  • Safer - You only pass what you intend to use/modify, and can't affect other data members in your DataContext.

However, this has the following possible cons:

  • Passing one parameter is likely to perform better than passing several/many
  • If your data requirements do change, then you have to change the interface to your object and all callers - a much higher maintenance overhead.

I would stick with separate parameters if the number of parameters is low (maybe 1-4) and you are pretty sure your data requirements won't change. If the number of parameters required is 5+ or you think the data requirements will change, I'd pass a single object.

There is a third option, which is to construct an intermediate object type by passing it the DataContext, and then pass this to your page. This means you have decoupling (potentially at both the call site and the called constructor because only the intermediate object needs to be directly coupled to the DataContext), encapsulation/protection (only the required data members from DataContext will be passed/used/changed), a single-parameter (efficient) call, and easy maintenance (knowledge of the parameters to copy are in one place, the intermediate object, rather than at every call site). The con of this is that you have to copy the data into and back out of the intermediate object which could affect performance. This approach may be useful, but consider the exact circumstances carefully before using it.

Upvotes: 1

Oded
Oded

Reputation: 498942

There is a refactoring called introduce parameter object.

The fact that it exists points to having an object instead of multiple parameters as being the more maintainable option.

This is a pattern used in the framework in multiple places - see Process and ProcessStartInfo - when an object can be configured multiple ways, supplying a configuration object (yes, that is tightly coupled to the object) is one design decision.

If the configuration object is only to be used with the object it configures, I don't really see a problem with this coupling.

Upvotes: 6

Related Questions