Tim Holloway wrote:An Interface is a contract. If a class implements an Interface, then it has promised that it will have implemented all of the methods defined in the Interface.
That's useful for a number of reason, including plug-replaceable components. And in particular test components.
If you have an interface definition you can construct a dummy or mock class that implements the indicated methods but does not have to actually do all the work that the "real" class does. That means that you can test your team's code without having to wait for the other team to deliver the "real" class.
Note that I distinguish between a "dummy" class and a "mock" class. In this context, a dummy class is simply a class that you implement yourself to test with. A Mock class is usually controlled by a mocking framework. Given a choice, I prefer dummy classes, but a mocked class can often be used in an environment where you need to pretend to connect to complex infrastructure and a dummy class can't be used.
Agreed. Let me frame and example on that. Correct me if i am going wrong
Ex:
public class House{};
public class RedHouse extends House{}
public class BlueHouse extends House{}
public interface Student{
House getHouse(List<House> houses,
String studentLastName);
}
dummy class :
public class StudentImpl imlements Student{
List<Houses> houses = new ArrayList<>();
houses.add("RedHouse");
houses.add("BlueHouse");
@Override
House getHouse(houses, "lastName"){
return houses.get(0);
}
}
My team can use this dummy class for testing and can write about House, RedHouse, BlueHouse etc.,
The other team can write the exact logic for getHouse with students last name and the houses list for a school. The other team will write the implementation of StudentImpl with business rules
Thus both teams can be engaged with interface as centric.