interface as parameter, and concrete class in method

[peter]

Hi, a "style" question.

There is a method which creates a user in a database. I have to instantiate
a user object, pass it to the method, and I get a completed user object
back.
public IUser Create(IUser user)
{
....
}

where IUser is an interface. Yet in the method itself I find things like:
((User)user).SetId(id);

Where User is a concrete class implementing IUser. Is this horrible? Or is
it perfectly reasonable? (The point of it seems to be to allow the
programmer to set some properties of the user object which the interface
does not declare - there are only getters). Does this mean that if I want to
supply my own implementation of IUser I really have to inherit from User and
not simply implement IUser and pass it to the method?

Thanks,
Peter

[Jon Skeet [C# MVP]]

peter wrote:

Hi, a "style" question.

There is a method which creates a user in a database. I have to instantiate
a user object, pass it to the method, and I get a completed user object
back.
public IUser Create(IUser user)
{
...
}

where IUser is an interface. Yet in the method itself I find things like:
((User)user).SetId(id);

Where User is a concrete class implementing IUser. Is this horrible? Or is
it perfectly reasonable? (The point of it seems to be to allow the
programmer to set some properties of the user object which the interface
does not declare - there are only getters). Does this mean that if I want to
supply my own implementation of IUser I really have to inherit from User and
not simply implement IUser and pass it to the method?

Well, it certainly looks like your Create method can't *really* work
with any IUser. If you want it to, you'll have to add some setters to
the interface. Otherwise, I'd consider changing that interface to take
User. Another alternative - create another interface IUpdatableUser or
something similar, with the setters on, and make User implement both
interfaces. Then you could return IUser but take IUpdateableUser.

Jon

[peter]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...

Well, it certainly looks like your Create method can't *really* work
with any IUser. If you want it to, you'll have to add some setters to
the interface. Otherwise, I'd consider changing that interface to take
User. Another alternative - create another interface IUpdatableUser or
something similar, with the setters on, and make User implement both
interfaces. Then you could return IUser but take IUpdateableUser.

Thanks for the suggestions. I have found this problem as I have made my own
"user" implementing IUser, passed it to the method and found that it fails
of course. While I do have access to see this CreateUser code I cannot
really change it as it is in use, along with the existing User - so I am
loathe to change them and have to face the possible repurcussions...

Thanks,
Peter

[Jon Skeet [C# MVP]]

peter wrote:

Well, it certainly looks like your Create method can't *really* work
with any IUser. If you want it to, you'll have to add some setters to
the interface. Otherwise, I'd consider changing that interface to take
User. Another alternative - create another interface IUpdatableUser or
something similar, with the setters on, and make User implement both
interfaces. Then you could return IUser but take IUpdateableUser.

Thanks for the suggestions. I have found this problem as I have made my own
"user" implementing IUser, passed it to the method and found that it fails
of course. While I do have access to see this CreateUser code I cannot
really change it as it is in use, along with the existing User - so I am
loathe to change them and have to face the possible repurcussions...

In that case, you've basically got to use the original User class (or a
derived class) instead of your own implementation of IUser,
unfortunately.

Jon