Originally posted by Marco K Paul:
Hello,
Should the param is takes in be another interface or should i let each concrete class specify the additional args.
Help me!Help you!!!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
java amateur
Originally posted by Marco K Paul:
Basically, the user selected a calculation type from a dropdown on the screen and in my business object, I have a switch statement that figures out which type of concrete instance to create. since i am using a switch statement, i know which params to pass in. this doesn't sound right to me :roll:
Moderator : <a href="http://groups.yahoo.com/group/OOAD_UML/" target="_blank" rel="nofollow">http://groups.yahoo.com/group/OOAD_UML/</a> <br />Home : <a href="http://www.zepho.com" target="_blank" rel="nofollow">http://www.zepho.com</a>
Originally posted by Marco K Paul:
Basically, the user selected a calculation type from a dropdown on the screen and in my business object, I have a switch statement that figures out which type of concrete instance to create. since i am using a switch statement, i know which params to pass in. this doesn't sound right to me :roll:
Originally posted by Ryan McGuire:
Does that help?
Originally posted by Ryan McGuire:
...and with good reason.![]()
Just pass the superset of parameters to the Calculate() method in each subclass, even if one or more may go unused. That way, once the client instantiates an object of the right class, it can just call Calculate() polymorphically.
Another possibility would be to pass in a reference to an object that would allow Calculate() to use getters to get any information they might need. This extra object might be just a Map or it might be some more specialized object. So let's say in the future you need to add a fifth possible ICalculateFees, which, unlike the previous four, needs to know the local county. The client would have to be modified to populate the Map with the county name (values.put("county", "Ashtabula")), but the other four ICalculateFees implementors could remain blissfully ignorant of the change.
Does that help?
If the interface is used by a client program to pass parameters(Say user supplied input values) to the one of the 4 calculating algorithms then you could have the calculate method take 3 paramters in the interface, 2 of which are common to all the implementing classes and one of type Collection to accomodate for additional paramters
Help me!Help you!!!
Thanks Ryan,Originally posted by Ryan McGuire:
My first paragraph IS a rehash of your solution. I had every intention of attributing that to you. I can't believe I missed that. Hold on while I go edit that. <MUZAK/>
I admit that my second approach is very close to what you suggested, but I figured the two differences...Using a Map so that the access method is by name instead of position Making the Map the only paramter so that access to the required data is homogeneous
was sufficient to warrent calling it new, or at least a non-trivial extension. I could have made those differences more clear.
Ryan
[ June 22, 2005: Message edited by: Ryan McGuire ]
Help me!Help you!!!
I would challenge you to a battle of wits, but I see you are unarmed - shakespear. Unarmed tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|