During the process of designing new features in your software, which process is the best practice
If going the route of number 2, when do you decide that an Interface is needed?
Well if you really go through the design phase, you'll have created the designs for the interface and class before coding either. Right?
The interface shows up when you need to refactor common features out of several classes.
Until you have multiple classes with common features, it's hard to foresee what the interface should be.
Once you have a few classes, it's much, much easier to reason out what the interface needs to be, then go back and refactor those classes to properly implement the newly-discovered interface.
Some folks design lots of classes on paper to figure out what the interfaces should be. Saves refactoring real code. Instead, you have to refactor your design.
Generally, you don't need an interface unless you have in mind several classes that will implement it. So, the interface would come first.
I would say the interfaces come first, but they come up as you are developing a particular class/method. When you hit a point that you know you have dependency on some other class/method, use an interface to add the dependency and keep writing your code. Then go back after your done writing the current component and create the components that implement the interfaces you need.
It all depends on the situation ...
When you know in the design-phase that you'll have multiple classes that have the same 'commonality', but their implementation differ, then the interface comes first.
However, software is organic; it is constantly evolving, so I can imagine that in some cases, you'll have a class and after some time it will be necessary to extract an interface from that class.
I would have to agree with S. Lott, adding that an Interface's design is "set in stone" once you create it.
For that reason alone, an Interface shouldn't be created until you know everything that it will contain.
I usually go with the second option. Write a class and extract interface later. Usually the reason for extracting an interface is the need for a second implementation of that interface (often as a mock for unit testing)
Ultimately, your design phase should come before your implementation phase regardless. Before you've begun coding you should have a strong picture of what the interactions between your classes will be, and hopefully your interface decisions will be obvious from that.
However, if you've already written a class, and now need to refactor it to have an interface, then keep in mind that the interface is simply selecting a set of functions/methods which have a common purpose which will be needed by more than one class. If you find that there are a few useful functions with your other classes will need, then those methods would be good candidates for an interface.
Another part of interfaces that makes them really useful is if you find that there are certain parts of your class that aren't private, but that you want hidden from certain other objects, in that case, you can take the functions you want exposed, and make them an interface.
I disagree strongly with anyone who says that you shouldn't design beforehand. Coders all love to jump straight into it, and sometimes, refactoring is necessary, but a strong design phase will save you huge amounts of refactoring time later.
Trick question! The test comes first. Then the implementation for the test, which is a class that may or may not implement an interface already. Part of making the test pass may involve extracting an interface out of an existing class, but don't try to guess what your interface will need before you have something that needs that interface.
You're going to drive yourself crazy trying to figure this out ahead of time--or at any rate, I always did in my pre-TDD days. Decide what functionality your app needs, write a test, and let that test guide what you do with your code.
The interface is the really important thing about most classes, since the implementation can be changed at any time, but once something's been provided in the interface it's difficult or impossible to retract it. To the rest of the project, the interface is what matters, and the implementation is somebody else's problem.
Ideally, the main features of the interface will be specified before any implementation work. (It's a good idea to design tests up front also.) The details can be allowed to evolve, but any changes to the interface should be based on what other classes and routines need, not artifacts of the implementation. The implementation should always be determined by the interface, not the other way around.
(Since this is a language-agnostic question, I'm assuming that the "interface" being discussed is the public functionality of the class, rather than, say, Java's replacement for C++ abstract classes. In C++, that would be the parts of the class definition marked "public".)
The class should come first.
A beautiful design can only be determined to be beautiful as it undergoes the crucible of change. How do you know if your interfaces will stand up to the test of time if they have were not forged from code to begin with?
I agree with Brian Guthrie. The test comes first, because it will drive your design. While this usually means ending up with a concrete class (the one you design by specifying its behaviour in as a set of tests), dependencies will commonly be expressed by means of interfaces (to allow for mocking and to follow the dependency inversion principle).
That often means you'll have the interfaces before you have the classes, but only because you need them earlier.
I don't know which is best, but I'm sure the right answer is always one of these two options in all contexts!
I would like to toss in two different views on what interfaces are:
However in both cases you design first, and then you code.
For a new system I would expect candidate interfaces to be identified first, which would later be implemented by classes. For an existing system, developing an interface from existing classes occurs when you discover of an important entity or point of variation in your system where it didn't was as important before or where you did not need to provide a point of variation before.
Which comes first? The need for a feature or the implementation of a feature?
In my own workflow, the interface comes first spontaneously. If some part of my project needs a new feature, it is built around how I want to use it, i.e., its interface. Then the implementation follows.
This way, the implementation contains only what is actually needed and no time is wasted in overengineering a shiny useless piece of code.
Interfaces evolve very bad over time. Whenever you change the interface you break the contract. All classes that implement the interface have to be refactored. To stay backwards compatible developers get creative and design IFoo2 over IFoo. This becomes a maintenance nightmare over time.
Regard the following: prefer defining classes over interfaces. Use interfaces when you want to provide a polymorphic hierarchy of value types. An other way of using interfaces is to achieve a similar effect to that of multiple inheritance.