I think it's in "Clean Architecture" where Bob Martin says that a lot of programmers believe that the true value of the system is in its behavior.
Yes, it's the behavior which businesses value, but as programmers - the people developing the software - we need to be aware of the maintenance cost of code that's associated with choosing a design that's too locked down.
Maybe I have a mislead view of software development. I know I can easily fix code that behaves incorrectly, but has tests and is verifiable. What I can't do is fix locked-down code which has neither tests or logging.
That makes the software a black box where I cannot even begin to reason about what the software is doing in a production environment.
If the cost for an extra layer of verifiability is an interface, then give me the damn interface!
The case where I see a need for an interface is when testing manager classes.
Even though my component class is a simple domain logic class which does not use outside resources, my manager doesn't care what the implementation of that component is.
Why should I complicate my tests with the extra set up data needed to test drive the manager class by making it depend on the concrete implementation of a component class? The component could be very complicated in nature, requiring a very complicated data setup.
Of course, nobody but that one class will ever use that interface, but the interface here will lower the amount of work needed to create the test in order to verify that the system works as intended.
That is more than enough benefit to warrant the interface's creation.
I think it's in "Clean Architecture" where Bob Martin says that a lot of programmers believe that the true value of the system is in its behavior.
Yes, it's the behavior which businesses value, but as programmers - the people developing the software - we need to be aware of the maintenance cost of code that's associated with choosing a design that's too locked down.
Maybe I have a mislead view of software development. I know I can easily fix code that behaves incorrectly, but has tests and is verifiable. What I can't do is fix locked-down code which has neither tests or logging.
That makes the software a black box where I cannot even begin to reason about what the software is doing in a production environment.
If the cost for an extra layer of verifiability is an interface, then give me the damn interface!
The case where I see a need for an interface is when testing manager classes.
Even though my component class is a simple domain logic class which does not use outside resources, my manager doesn't care what the implementation of that component is.
Why should I complicate my tests with the extra set up data needed to test drive the manager class by making it depend on the concrete implementation of a component class? The component could be very complicated in nature, requiring a very complicated data setup.
Of course, nobody but that one class will ever use that interface, but the interface here will lower the amount of work needed to create the test in order to verify that the system works as intended.
That is more than enough benefit to warrant the interface's creation.
I could not have said it any better.
Thanks for your feedback, Mykezero.