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?