interfaces for data classes

[Peter]

Hi

I was wondering about the use of interfaces for "data classes".
Actually I don't know the accepted term for these types of classes -
they are simply classes which have getters and setters, to contain data
and not really provide any functions.

Is it worth defining interfaces for these types of classes, or is it
"overkill"?

Eg. I might have a class like:

public class User : IUser
{
public string Name { get; set; }
public string Address { get; set; }
public DateTime Birthdate { get; set; }
}

public interface IUser
{
string Name { get; }
string Address { get; }
DateTime Birthdate { get; }
}

In this case, the interface only defines the getters, but setters might
also be defined.

And some other class creates the user objects in a method:

public IUser GetUser()
{
User user = new User();
// set properties
return user;
}





Thanks,
Peter

 

[Marc Gravell]

In most common scenarios, an interface here would be overkill and add
confusion. Additionally, coding against an interface (rather than a
class) has implications for data-binding (no inherited members, no
automatic new rows in grids), serialization (xml/dcs won't work) and
generics (no "new()" constraint). And probably many more.

There are some cases when it might be useful, but if you can't see
that it gains you anything then don't do it. Apart from anything else,
it is extra code to maintain for no good reason.

Marc

 

[Clive Dixon]

If your goal is to restrict certain properties to be read-only to public
users, then if you're using C# 2.0 or above you could perhaps (depending on
your project architecture) change the access level of your set property
instead:

public string Name
{
get
{
}
internal set
{
}
}

 

[sloan]

Even when it seems like overkill, I would consider it more of a discipline.
You have to get used to referring to things by their interface name "on the
outside world" rather than their concrete implementation.

Writing and using a bunch of concrete classes all the time is not OO
programming.

User u = new User();

vs

IUser u = new User();
OR
IUser u = UserFactory.CreateNewUser();

Your controller classes definately need interfaces......

IUserController
IUser GetSingleUser(int customerId)
IUserCollection GetAllUsers()
void UpdateSingleUser(IUser u)

You would see this very clearly with how WCF forces a contract....


But I 'hear ya', especially when you know you're only going to have 1
concrete for pretty much "all time", it seems like overkill a tad....
but go ahead and discipline yourself, and the one day that it really pays
off in a big way, you'll be like "Man, I'm glad I took that extra 4 minutes
back then".

One off shoot advantage is that you'll always be able to see a very clean
contract when you look at the interface definition.
Aka, when you pull up the code for IUser, it'll just be the contract, and
its much easier to look at then a concrete with lots and lots and lots of
lines of code.

I'm sure you'll get some other comments. Those are just a few from my side.

.............

Here's a small (downloadable) example of interfaces and WCF btw:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry

 

[Marc Gravell]

Writing and using a bunch of concrete classes all the time is not OO

programming.

The choice to use an interface or a class is not a determining factor
in whether it is OO (ideally so long as both coding styles are
available for when each is appropriate).

You would see this very clearly with how WCF forces a contract....

WCF forces an interface for the service (methods etc) - but not for
the data objects.

Typically in WCF the data objects would be classes; [DataContract]
isn't even valid for interfaces. You can /possibly/ get this working
via assembly sharing, but the regular "mex" hooks don't like this very
much - things become "object" etc. I don't have access to the link you
posted, so I can't see what it does.

Marc