Method overloading does this look right to you?

[Lenn]

I have the following method:

public void Execute(TCPComm and 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(TCPComm and 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]

Re: Method overloading does this look right to you?

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.

"Lenn" <Lenn@discussio ns.microsoft.co m> wrote in message
news:79FB6ABD-BE17-4B1A-A63E-71D36592E135@mi crosoft.com...[color=blue]
>I have the following method:
>
> public void Execute(TCPComm and 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(TCPComm and 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![/color]

[Jon Skeet [C# MVP]]

Re: Method overloading does this look right to you?

Marina <someone@nospam .com> wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Lenn]

Re: Method overloading does this look right to you?

> First of all, it looks like you are passing in the same object for both[color=blue]
> 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.[/color]

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.

[color=blue]
> 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.[/color]

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]

Re: Method overloading does this look right to you?

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.

"Lenn" <Lenn@discussio ns.microsoft.co m> wrote in message
news:C9E2DB9D-2CB1-45C8-AAF9-F0582392107C@mi crosoft.com...[color=blue][color=green]
>> 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.[/color]
>
> 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.
>
>[color=green]
>> 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.[/color]
>
> 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.[/color]