When do you need to create abstractions as interfaces?

Question

When do you encourage programming to an interface rather than directly to a particular class?

The guidance that I follow is to create abstractions when the code requires crossing the logical / physical border, especially when it comes to infrastructure problems.

Another control point will be that the dependency is likely to change in the future due to possible additional problematic codes (such as caching, transaction awareness, calling a web service instead of executing in the process) or if such dependencies have direct links to infrastructure of integration points.

If the code depends on what does not require control in order to cross the logical / physical border, I more or less do not create abstractions for interacting with them.

Did I miss something?

Answer 1

Also use interfaces when

• Several objects will need to act in a certain way, but they do not have a fundamental connection. Perhaps many of your business objects refer to a specific utility object, and when they need it, they need to give a link to this utility object so that the utility object can call a specific method. Have this method in the interface and pass this interface to this utility object.

• Passing interfaces as parameters can be very useful in unit testing. Even if you have only one type of object that supports a specific interface and, therefore, does not need a specific interface, you can define / implement an interface exclusively for " fake " this object in unit tests.

• associated with the first two bullets, check the observer pattern and dependency injection . I am not saying to implement these patterns, but they illustrate the types of places where the interfaces are really useful.

• Another twist on this is the implementation of a pair of SOLID Principals, Open Closed main and Interface Separation Principles . Like the previous bullet, do not pay attention to the strict implementation of these principles all over the world (right away), but use these concepts to help move your thinking away from which objects go, where to think more about contracts and dependencies.

• In the end, it's not too complicated: we are in a strongly typed .NET world. If you need to call a method or set a property, but the object you pass / use can be fundamentally different, use the interface.

I would add that if your code does not reference another library (at least for a while), then the decision about whether to use the interface in a specific situation is one that you can deferred responsibly. Extract interface refactoring is easy to do these days. In my current project, I have an object that is being passed to me, I think I should switch to the interface; I do not emphasize this.

Answer 2

Interface abstraction is convenient when performing unit test. This helps mock test objects. This is very useful in TDD for development without actually using data from your database.

Answer 3

If you do not need any class functions that are not found in the interface ... then why is the implementation of the interface not always preferable?

This will simplify your code in the future and will be easier to test (mock).

Answer 4

you have the right idea. I would add only a couple of notes to this ...

firstly, abstraction does not mean "interface". for example, the “connection string” is an abstraction, although it is just a string ... it’s not about the “type” of the thing in question, but about the intention to use it for this thing.

and secondly, if you are testing automation of any kind, look for the pain and friction that are being written in the tests. if you need to set up too many external conditions for the test, this is a sign that you need a better abstraction between the thing of your testing and what it interacts with.

Answer 5

I think you said it pretty well. Most of this will be stylistic. There are open source projects. I looked where everything has an interface and an implementation, and this is partly disappointing, but it can make iterative development a little easier, since any object implementations can break, but dummies will still work. But honestly, I can fake any class that does not abuse the final keyword by inheritance.

I would add the following to your list: everything that can be considered as a black box should be abstracted. This includes some of the things you mentioned, but also includes hairy algorithms that are likely to have many useful implementations with various advantages for different situations.

In addition, interfaces are very often used with compound objects. This is the only way to get something like a java swing library, but it can also be useful for more mundane objects. (I personally like to have an interface like ValidityChecker , with methods for compiling and / or compiling subordinate ValidityChecker s.)

Answer 6

Most of the useful things that come with the interface have already been said. However, I would add:

• implementation of an interface to an object or later several objects, FORCES, all developers follow the IDENTICAL pattern to implement a contract with an object. This can be useful if you do not have OOP-experienced programmers who actually write implementation code.
• in some languages, you can add attributes on the interface itself, which may differ from the actual attribute of the object’s implementation as meaning and intent