The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How Should I Pass Parameters To A Class Method

I have a class which usually produces XML, sometimes it produces a CSV file however, depending on the customer I need to transport the XML/CSV via different methods.

One customer might want it sent as an e-mail body, another as an e-mail attachment, a third via FTP and another via a bespoke Java framework for which I simply have to copy the file into a directory on the network and the framework takes care of sending it.

I figure I'm best off creating various "transport" classes and then perhaps the message handling class can call the Despatch() method of each transport class.

Obviously, FTP requires different set-up parameters (server, username, password, directory, filename) than SMTP (e-mail address(es), title, body/attachment?) and unc (filename, path).

My question is, how should I pass the various parameters to these transport classes?

I can either go with passing them as individual parameters to the Despatch method but then each call in the controlling class needs to be aware of and call a different version of Despatch with a different number of parameters for each message it handles?

I could pass some kind of parameter class instance which each transport class knows how to handle its own version of. Trouble is, don't I then need to remember to change the parameter class everytime I add a new transport class?

I could just pass an associative array (key:value) and let the transport class just look for the keys that matter to it from the array? The message handling class still needs to know what key:values to include for each transport class so I'm still going to have to change classes additional to any new transport classes I add in order to support the new transport's required parameters? However, I think I favour this approach.

Or something else...?

Any advice on what might work best would be really appreciated?
Charley Farley
Monday, October 10, 2005
You could create a Transport class or interface that the file generation class outputs to.

The caller would pass an instantiated and configured transport class to the generator class which does not need to know what is happening to the output.

A class factory could be used to generate pre-configured transport objects inline with you current customer's configuration.

A Stream is a good example of the technique. You could pass in a memory stream, or a network or file steam.

Hope this helps.
Tim H Send private email
Monday, October 10, 2005
>> I could pass some kind of parameter class instance which each transport class knows how to handle its own version of. Trouble is, don't I then need to remember to change the parameter class everytime I add a new transport class?

I find this the best solution. However, you won't always pass the Parameter class; instead you will pass instances of subclasses of the Parameter class (like Transport1Parameter, Transport2Parameter...). Of course you will need to subclass Parameter for every Transport you create, but Parameter itself will not change.
Ioan Bizau
Monday, October 10, 2005
And it might look better if "Dispatch" was spelled correctly in the code..
Monday, October 10, 2005
I'd pass the payload to the Dispatch method along with a customer ID of some sort.

Then the Dispatch method can look up the prefered delivery method based on the customer ID.  Once it passes the payload into the delivery method, you can look up the required parameters via customer ID.

This will allow *each* customer to have a distinct method along with distinct parameters.  In fact, a given customer could have two methods, you'd just have to ID them differently.
KC Send private email
Monday, October 10, 2005
Thanks all for your comments.

sloop: It may be the UK/US difference but despatch = dispatch - see

I'm in the UK and I spell it "despatch". There are others in the UK who spell it "dispatch" and I believe neither is incorrect.

I am reasonably inexperienced with OO stuff.

Taking Tim H's TransportFactory suggestion...

I figure calling something like this from the client for each customer's message:

TransportFactory.getTransport( cust.transportType, cust.transportParameters )

Where transportParameters is an associative array of key:values would do the trick?

The TransportFactory can then encapsulate all the specific code required for each concrete Transport class in order to return the appropriately instantiated Transport instance.

Does this sound reasonable?
Charley Farley
Monday, October 10, 2005
Sounds like you are on the right track.

The purpose of the factory was to put all the knowledge of construction and configuration of concrete transport objects into one place so that you did not have to replicate this code throughout your application.

For example:


This method would read config info for this installation and return an FTP transported for one solution, and a pigeon carrier for an other.

This method could be parameterised with CustomerID if you system needs to cater for different customers simultaneously.
Tim H Send private email
Monday, October 10, 2005
> TransportFactory.GetTransporter()

Is that how the movie Transporter 3 will be made?
son of parnas
Monday, October 10, 2005
Great. Thanks for all your comments even if I didn't "get" son of parnas's post.

Charley Farley
Monday, October 10, 2005
"And it might look better if "Dispatch" was spelled correctly in the code.."

And were you more widely read, you wouldn't have batted an eye at it.
Kyralessa Send private email
Monday, October 10, 2005
Personally, I'd still use "Dispatch".  To me, that reads as "Dis-patch", or "send it".  "Despatch" reads to me as "De-spatch", or to un-spatch something (whatever 'spatching' something means -- something to do with spackle, I assume).

But of course, it's up to you. <end sillyness>
Monday, October 10, 2005
If you want to be OO about it (and why not), how about this:

- a "User" object which has (as well as obvious personal info) some kind of enum that says how they are to receive messages, available by a get method, and a method to get addressing info.

- a "Message" object which holds the message content, and has a reference to a User object called "destination". It also has a "send" method that looks up the destination, finds out how to send itself, and then calls some underlying library code to actually do the email/ftp/print off a postcard/allocate a carrier pigeon.
revert my buffer
Tuesday, October 11, 2005
You have different implementations of things (transport) but you haven't realy said if they have a standard interface between them.

I'd have a generic top level class for transport that your going to give the file, and then derived classes which are instantiated with the specific type (email, file, ftp, etc.).

Now instead of passing some 'list of paramters' to initialise later, you initialise up front, and just pass the object which provides the one generic interface.

class transport{ send(string) )
class ftp : public transport( ftp( address, login ); send(string) { // put the content } }
class email : public transport( email( address ); send(string) { // run xmail } }

class preparefile{ prepare( transport & t ){ string a = "content"; t.send( a ); }

  transport * a = new ftp( "", "Joe/Foo" );
  transport * b = new email( "" );

  preparefile output;

  output.prepare( a );
  output.prepare( b );

Monday, October 17, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz