1

I try to program to an interface whenever possible, but its not clear to me how I could apply it to a model as broad as a user. Which can hold many disparate fields (name, age, phone number, ssn, etc.) or be composed of many modules.

I could design a general purpose library of functionality for use across applications, that would take in an ICallable to make a phone call or INameable to display a name to the console. But in the end the user class (how the data is accessed and/or stored) would be unique to an application and its needs.

If I try to design the user and consumers in the library (stated above) to communicate by interface, I get an "interface soup" (or something "hydra-esque") on the user class. Where it feels like I'm extending an interface for almost every attribute or module.

public class Employee : INameable, ICallable, IAgeable, IPayable ...

Is this particularly wrong? Am I taking interface use too far by completely avoiding the injection of concrete classes into the consumer (and preventing more general use)?

Whats a better approach to this problem?

profile
  • 25
  • 2

3 Answers3

1

It's not wrong. It might be a hint that your class is too big for its shoes in the first place and you should refactor it, but that has nothing to do with programming against interfaces.

If you follow the principle that complex functionality should deal with interface types rather than concrete types, then your concrete class must wear all those interface "hats". The fact that it declares a long list of them is just an expression of the fact that it does many things.

As it is, the interfaces you're extending are all different things, so this long list is not a violation of DRY that you might somehow get rid off.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
0

I've also had concrete classes implement a handful of interfaces, but the classes have been mediators that delegate their behavior to single-responsibility classes that each satisfy a single interface. The mediation class itself has little behavior outside of determining how the individual modules will interact and be utilized. That mediation becomes its one responsibility, so SRP is preserved.

redman
  • 121
  • 4
0

We should not forget that the whole is greater than the sum of its parts. I could imagine a situation where a user exists and his phone number is unknown.. Is the user an instance of ICallable? To be 'callable' and to be 'a user' are two different things. So, design of your interfaces should reflect this notion.

I think that your question is not about technical aspects, but rather about your domain area.

Leonid Breido
  • 1
  • 1