CODEWITHSUNDEEP
c#.netoop
newdayrising
newdayrising

Reputation: 3802

Is it worth creating an interface for a trivial return type?

Consider the following interfaces:

public interface IPlayerRepository
{
  IPlayerInfo GetPlayerInfo(int id);
}

public interface IPlayerInfo
{
  public int Id { get; set; }
  public int GamesPlayed { get; set; }
  public int GamesWon { get; set; }
}

and the associated implementations:

public class PlayerRepository : IPlayerRepository
{
  IPlayerInfo GetPlayerInfo(int id)
  {
    // read from external data store
    return new PlayerInfo();
  }
}

public class PlayerInfo : IPlayerInfo
{
  public int Id { get; set; }
  public int GamesPlayed { get; set; }
  public int GamesWon { get; set; }
}

Is there any value in having the separate IPlayerInfo interface, given that the class only exists as a collection of properties to be returned by this method? Would it be preferable to just have the IPlayerRepository.GetPlayerInfo method return a concrete PlayerInfo object?

Upvotes: 2

Views: 130

Answers (5)

Doug Chamberlain
Doug Chamberlain

Reputation: 11351

IMO. Don't try to write code for a type that you haven't thought of yet. I find it's always easier to write code that makes sense, and isn't overly abstracted or overly complicated. You can always refactor it when you get to the point where your requirements change and you have more than one type of PlayerInfo that will require a different implementation.

Upvotes: 1

Fiona - myaccessible.website
Fiona - myaccessible.website

Reputation: 14921

It's not just whether you will ever have a different kind of an entity, but also whether it will need mocking during testing.

If your entity will never perform any business logic, I wouldn't bother, personally.

Upvotes: 1

Thomas
Thomas

Reputation: 182000

If you plan on creating mockups for unit testing, this might be worthwhile. In this particular case, it might be worth mocking the IPlayerRepository, but probably not the IPlayerInfo.

Upvotes: 3

THX-1138
THX-1138

Reputation: 21750

PlayerInfo is just a simple data-storage-structure, and does not have much of a contract to formalize in a form of an interface. I avoid creating interfaces for classes that don't really DO anything.

Upvotes: 1

user541686
user541686

Reputation: 210685

If you think you can have more than one kind of PlayerInfo (which is likely to be the case if PlayerInfo is a class and not a struct), then yes. If it's something that'll probably never change, then probably not.

Upvotes: 5

Related Questions