3

Is it bad design to expect the client to cast between interfaces? I understand it can be done, but is it clean? I'm comparing retirement profiles in a simulation. I have 2 different types of TSPs (think 401k). I have a TSP class, which holds employee contributions (no government match). MatchingTSP is a TSP, but it also includes government matching contributions. Looking specifically at this case:

--MY DOMAIN MODEL--

interface ITSP
{
  public void MakeContribution(...);
  public double CalculateContributionByYear(int year);
  public double CalculateCumulativeContributions(...);
  public double CalculateTotal(...);
}

class TSP : public ITSP
{
  public virtual void MakeContribution(...) {...}
  public virtual double CalculateContributionByYear(int year) {...}
  public virtual double CalculateCumulativeContributions(...) {...}
  public virtual double CalculateTotal(...) {...}

  private IList<TSPContribution> contributions;
}

interface IMatchableTSP
{
  public void MakeContribution(...);
  public double CalculateContributionByYear(int year);
  public double CalculateCumulativeContributions(...);
  public double CalculateTotal(...);
}

class MatchableTSP : public TSP, IMatchableTSP
{
  public override void MakeContribution(...) {...}
  public override CalculateContributionByYear(int year) {...}
  public override CalculateCumulativeContributions(...) {...}
  public override CalculateTotal(...) {...}

  private IList<TSPContribution> contributions;
}

--CLIENT USE--

ITSP johnTSP = TSPFactory.CreateTSP();
ITSP jimTSP = TSPFactory.CreateMatchableTSP();

// Print BaseTSP Employee Contributions
Console.WriteLine(johnTSP.CalculateCumulativeContributions());
Console.WriteLine(jim.TSP.CalculateCumulativeContributions());

// Print MatchingTSP Contributions
Console.WriteLine((IMatchableTSP)jim.TSP.CalculateCumulativeContributions()); 

So I see two problems here: the client needs to cast between different interfaces to get different types of data. The interfaces are duplicated (violating DRY) to allow this casting between interfaces.

Should I use casting to get the different data that I want (e.g. employee contributions vs government matching contributions) or should I add new methods in MatchingTSP that include MakeMatchingContribution(...), CalculateMatchingContributionByYear(int year), etc.

  • So I'm guessing the factory method CreateMatchableTSP doesn't return an IMatchableTSP. Why is that? Also, it seems like IMatchableTSP should just inherit from ITSP. Is there a reason it doesn't? (Also, not quite sure what language you are using, so that might explain why you can't do some of the things I'm thinking you should be able to.) – Becuzz Dec 12 '17 at 16:59
  • IMatchableTPS could just inherit from ITSP like a marker interface (and probably makes most sense). Factory.Createxxxx methods can return either. This was more of a design question, is it clean for clients to cast to different interfaces to get the data they need? – keelerjr12 Dec 12 '17 at 17:04
  • Functionally, what is the difference between MatchableTSP and plain ol' TSP? All your interfaces and implementations look identical. – MetaFight Dec 12 '17 at 17:07
  • @MetaFight, I'm comparing retirement profiles in a simulation. I have 2 different types of TSPs (think 401k). I have TSP which is just an employee putting in contributions (no government match). MatchingTSP is a TSP, but it also includes government matching contributions. – keelerjr12 Dec 12 '17 at 17:11
  • 3
    I think you're modelling this incorrectly. You're describing two TSPs. They don't need distinct types to differentiate them. They only need to be different instances. – MetaFight Dec 12 '17 at 17:17
1

Should I use casting to get the different data that I want

No. Using the same name for two different methods that do different things can't be a good idea. Using the same name for two different methods that return different data, where both methods can both be implemented by the same object, is bound to cause confusion.

should I add new methods in MatchingTSP

Yes. There's no reason not to create new methods for the additional tasks that are involved in conforming to IMatchableTSP. Just doing that will make life less confusing for people using your interfaces, and you can probably avoid a whole class of confusion-related bugs just by choosing clear names.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.