 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / September 2005Method overloading does this look right to you?
I have the following method: public void Execute(TCPCommand command, out string outputResponse, out string error) { //snipped code outputResponse = "some message"; error = ""; } now I need to a new overload for this without error and output parameters: public void Execute(TCPCommand command) { string param; Execute(command, out param, out param); } But it doesn't feel right declaring new string variable just for that.. Is there a way to pass in "null" references. String.Empty doesn't work. Or is this the best way to handle something like this. Thanks! First of all, it looks like you are passing in the same object for both parameters. That means whichever one's value you set last, that will be what is in that variable. So that doesn't really help you. I would in this case have Execute return an object (so you define a new class for this), with properties OutputResponse and ErrorMessage or something like that. It would then need just the 'command', to tell it what to do, so you would only have one version of the method. You can always just ignore the return value of Execute if you don't care about the output or error messages. And, it means that if in the future there are is any other information for Execute to return, you can just add it to that return class. >I have the following method: > [quoted text clipped - 19 lines] > > Thanks! > First of all, it looks like you are passing in the same object for both > parameters. That means whichever one's value you set last, that will be what > is in that variable. So that doesn't really help you. It does, because the point is that the method being called really doesn't care about the value put into the response/error - it's not doing anything with it afterwards. > I would in this case have Execute return an object (so you define a new > class for this), with properties OutputResponse and ErrorMessage or [quoted text clipped - 3 lines] > error messages. And, it means that if in the future there are is any other > information for Execute to return, you can just add it to that return class. Yes, that sounds like a better idea to me - or perhaps just returning a string and throwing an exception on error, unless getting an error *really* isn't fatal as far as the method itself is concerned.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > First of all, it looks like you are passing in the same object for both > parameters. That means whichever one's value you set last, that will be what > is in that variable. So that doesn't really help you. Let me try to explain, there are some clients that care about Error and response and some clients that don't. If a client calls Execute overload without error and response, obviously it doesn't care. So it doesn't matter what the value is for those params since those params never get to the client. > I would in this case have Execute return an object (so you define a new > class for this), with properties OutputResponse and ErrorMessage or [quoted text clipped - 3 lines] > error messages. And, it means that if in the future there are is any other > information for Execute to return, you can just add it to that return class. I already have a client app that use this class. It relies on errors and response output params. However I need to write a new client and requirements dictate that this client doesn't care for any errors or output, because none will be returned. So I want to write new overload without error and response params, but I don't want to break existing working client either. I could just have new client pass in those params and ignore them, but overload seemed like the most logical way. Ok, I just sort of said that in case that overload may do something with those parameters. I guess not. In any case, declaring a new string variable, just to have something to pass in is not a big deal. >> First of all, it looks like you are passing in the same object for both >> parameters. That means whichever one's value you set last, that will be [quoted text clipped - 30 lines] > just have new client pass in those params and ignore them, but overload > seemed like the most logical way. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.