1

This question already has an answer here:

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?

marked as duplicate by gnat, user22815, user53019, durron597, user40980 Jul 8 '15 at 0:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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.

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.

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.

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