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.

Passing a Dictionary or Custom Class as a Constructor Parameter?

I am planning a bunch of classes (it's classic ASP so the Object-Orientedness of my design is limited - just like my knowledge of OOD!) that deliver a text message to business partners using a variety of mechanisms; UNC, FTP, SMTP attachment, SMTP body and obviously, one day some currently unknown methods. Each partner may use a different method. I'd also like to be able to send the message by more than one method to each partner but that's not the issue here.

Obviously, each transport generally has its own unique, required addressing information:

FTP: server, username, password, path, filename
SMTP attachment: "to", "from", "subject", filename
SMTP body: "to", "from", "subject"
UNC: path, filename
FUTURE: who knows?

I'm planning on doing something like this in the client:

If the Dictionary (classic ASP’s key/value collection), connectParams contains:
"server"=>"ftp.customer.com"
"username"=>"user"
"password"=>"pwd"
"path"=>"/"
"filename"=>"daily.xml"

This is easily created and populated with a SQL SELECT from a customerId, property, value table in a database.

Then,

Set transport = TransportFactory.createTransport( "FTP", connectParams )
transport.deliver( message )

Returns a concrete FTPTransport instance with all the information needed to connect and deliver the message passed via the deliver() method.

Likewise:

If the Dictionary, connectParams contains:
"to"=>"sales@customer.com"
"from"=>"us@ourdomain.com"
"subject"=>"Your daily XML message"

Set transport = TransportFactory.createTransport( "SMTPAsBody", connectParams )
transport.deliver( message )

Returns a concrete SMTPAsBodyTransport instance with all the information needed to connect and deliver the message passed via the deliver() method.


I can easily create the in the client for each business partner and pass this to the transport factory createTransport method. The actual concrete Transport object that the factory creates can also easily check the dictionary keys to ensure it has all the information it needs or else fail appropriately.  I'd pass the message (always simply a string, usually XML or CSV) in the deliver method and the concrete Transport object can do what it needs to deliver the message.

This would seem to work quite well, in my head.

However, I wonder whether I should really be creating a bunch of TransportInformation classes, one per concrete Transport type and passing those in place of a Dictionary connectParams parameter?

Would you consider passing the Dictionary as "cheating"? It's obviously less OO than passing a class built for the purpose but the TransportInformation classes seem a little like over-engineering?

If you think creating and passing specific TransportInformation classes to the concrete Transport method is appropriate, then I still have to instantiate them and I still have to get the bespoke (per transport type) connection detail properties into to them. I can see myself passing THAT dictionary again to the TransportInformation class' constructor (see Notes below) instead and then I'm back at square one – cheating?!

Notes

Classic ASP classes don't support parameterised constructors so I usually end up with a two-phase process:

Set transport = New FTPTransport
transport.construct( connectParams )

This is usually coded in one place, the Factory so forgetting to call the construct() method is not something that tends to be forgotten.
Mr. Fandango
Wednesday, February 01, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz