Should you create an interface when there (currently) will be only one class that implements it?

Question

If you always create an interface, if there is a possibility that there may be something else that can use it, or wait for the actual need for it, then will refactoring use the interface?

Programming on the interface usually seems like a sound advice, but then there is YAGNI ...

Perhaps this depends on the situation. Right now I have an object representing a folder that may contain recipes or other folders. Instead of using Folder directly, should I worry about implementing something like IContainer? In case in the future I want to have a recipe that applies to other sub-recipes (say, an apple pie recipe, which is also a container for a pie cake recipe)

Answer 1

It always depends on the situation. If you know that there will be another class using the interface, then yes, create an interface class to save time later. However, if you are not sure (and most of the time you did not), wait until you need it.

Now this does not mean to ignore the possibility of an interface - think about object public methods and such with the aim of making an interface later, but do not clutter up your code base with what you REALLY NEED.

Answer 2

There will always be a test that uses it, right (you do unit tests, right?). This means that it always uses classes N + 1, where N is the number of classes that your class uses in the application.

Another goal of an interface, besides dependency injection, is to share anxiety, so that your class can actually implement multiple interfaces.

Keep this in mind, but you can always use the interface introduced later through refactoring if it is not implemented at the beginning.

Answer 3

As a rule, you should not worry about creating an interface if only one class is going to implement it, even if you expect a possible class for it, because there may be problems with the implementation that will not arise until the class is actually tested in the script, in this In the case of a prematurely created interface, there may be too many members or a member may be missing.

For example, the .NET Framework Bas Class Library team allowed SyncRoot prematurely design when it included the SyncRoot property. For a later universal ICollection<T> they decided to remove it ( http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx ).

If you are going to create a dummy object that implements the same interface, then this will be considered the second implementation that justifies the creation of the interface. However, not all unit tests guarantee a layout-style interface.

Answer 4

I would say that it depends more on how many places you are going to use in the class, and less on how many classes the interface can implement. If you use only a folder in one or two places, I would say wait until there is an urgent need for an interface before you implement and refactor it. However, if you use Folder in 100 different places, you can save some time by programming the interface in the foreground.

Answer 5

Think of an interface as a contract to define semantics or concepts. This is a general approach and not a very specific language. In the context of OO, if you work in the same inheritance model, there is a great example for preferring interfaces over classes to define your object model, as this single superclass path is quite valuable, and you want to keep it for something more “significant” than the definition properties that are exposed to the object or methods.

So that the semantics of IContainer (contract) is a pretty bad reason to make an interface from your folder; it is better to have your own folder (if it runs any non-trivial logic) "implements" (probably already existing) the IContainer or ICollection interface in your language frameworks.

As always, the best choice is quite dependent on the specific problem. In the case of your recipes, which are also folders (?!), You probably think about the parent-child or composition, attitude - semantics, which can (and should) be expressed using interfaces if you have other elements in your system "work" with things that consist of this semantics.

There is a bit of overhead (programming) with interfaces, and if you find that when you are done, nothing more than a set of Woof and IWoof classes and interfaces, then you will find out that you probably need to express your problem in terms of interfaces - simple classes would be enough.

As a rule, for any I, you should have at least a few specific classes (with more meaningful names other than IImpl, or).

Hope this helps.

Answer 6

Many people have already provided some very useful tips. One thing that I would like to add is that if you want to avoid direct hard dependencies on specific classes, then the interfaces will help, providing free communication. If you are creating an architecture with a plug-in, then the interfaces are definitely suitable for work. In addition, if you plan to write unit tests either side by side or later on a line, you will probably notice that the code that calls into your class (s) of the folder will need to perform a specific implementation so that the calling code is testable, If your specific implementation of the class (s) of the folder, in turn, will talk to the database or service, then you will need to have what is transferred to your tests, and this will quickly become cumbersome. Only my 2 cents.