Interfaces design question

  • Thread starter Thread starter Learning SQL Server
  • Start date Start date
L

Learning SQL Server

I have a base class (say, BaseUser) in my class library that 3 other classes
derive from:

UserTom
UserDick
UserHarry

Additionally, a fourth class that contains some administrative functions has
a method, SaveUser, that takes one of my derived classes as an argument.

Ideally, I would like to take a "generic" (read - base) object in as the
argument then determine at runtime what the object is and act accordingly.
The way I see it now, I would have to write 3 overloaded methods, each
taking a different BaseUser derived class:

SaveUser(user UserTom)
SaveUser(user UserDick)
SaveUser(user UserHarry)

When instead in my fourth class I would rather have:
SaveUser(user BaseUser)

Being a C# n00b, I am unclear as to the best design pattern for this
situation. I think it clearly is a case for an Interface (each class shares
the exact same fields and members). Should I include a SaveUser method
within the interface and implement it in each derived classes? this doesnt
seem right to me, as the implementations across the board will be exactly
the same.

Am I making any sense? Can someone steer me in the right direction?
 
My first guess is that you are confusing different objects with
inheritance. Inheritance implies a specialization. Objects can have
state
so that you can identify an object as Tom, Dick and Harry.

http://www.geocities.com/jeff_louie/oop.htm

Regards,
Jeff
I have a base class (say, BaseUser) in my class library that 3 other
classes
derive from:

UserTom
UserDick
UserHarry<
 
Back
Top