Method overloading does this look right to you?

[Guest]

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!

 

[Marina]

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.

 

[Jon Skeet [C# MVP]]

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
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.

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.

 

[Guest]

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
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 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.

 

[Marina]

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.