Interfaces in Dynamic Languages
I have been introducing a lot of interfaces in our code base at work. At one point, this has led me to think if they are really useful.
Back when I was programming in Java, I used interfaces to aid in “decoupling” my code. By decouple I mean separating concerns — business logic shouldn’t be mixed with crud logic. The latter should delegated to another object where the appropriate method is called. Working with PHP, however, I realized that this can be done by simply creating separate classes for business logic and crud operations. No need for interfaces. It will work just fine.
So the only need I had left for interfaces was for constructing mock objects for my unit tests — specifically so that I wouldn’t be dependent on a database to unit test my service layers. I can just write a mock dao that returns mock data and then inject it wherever it is needed.
Yes mocks are needed for unit tests but was implementing the
interface necessary? The code works just as well without having it
I have found though that one good argument for interfaces is to check if an object supports a set of methods. This is especially crucial if one expects an object to be able to support a large set of methods. An object injected into a dependent object that doesn’t implement the interface required is automatically rejected even before it is used a.k.a at compile time. In dynamic languages, I reckon this rejection happens at run time.
For a large team of developers who don’t know each other, interfaces are a good mechanism to formalize functional requirements. But I work in a three person team where I am the only one working on my module. The only reason I can think of right now to use interfaces is for the benefit of the developer after me who will be maintaining the code I write.
The question now is, are interfaces any useful in a dynamic language given that type checking isn’t done till runtime? What other value does that give you?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)