A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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:
This is easily created and populated with a SQL SELECT from a customerId, property, value table in a database.
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.
If the Dictionary, connectParams contains:
"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?!
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.
Wednesday, February 01, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz