Within one week I reviewed two bowling game solutions having lots of interfaces, each of them with only one implementing class. What is the use of that? Being able to enhance it easily? Some leftovers from C++? Did they read it in some books or learn it in university, and if so – who teaches this? Sure, using interfaces even if they only have one implementation is a good thing if you have to provide an API to your code so that others might overwrite your implementations easily… but why do it here? Those interfaces just make it harder to find the part of your code which is actually doing something.
I just don’t get it and would like to recommend you the YAGNI principle. Makes your code better and code reviewing more fun.
I’m not a candidate but I wanted to comment on this post.
First of all, It’s called manageable code, I for one definitely promote the use of interfaces, and on the contrary, if i were reviewing code as part of an interview process I would most surely check the architecture of the application, believe me, I have had to work with to many people from a C background who can’t fathom OOD concepts (such as programming by interfaces) and the code they write is horrible.
As for not being able to find a functional piece of code because of interfaces… this is ridiculous, either you don’t understand the use of interfaces yourself, or the application of them in the code you are reviewing is completely wrong. Interfaces are not necessarily used just for public APIs, they are meant to modularise code and allow us to implement patterns to make the code easier to maintain and extend. Besides that fact, if you think of yourself as a half decent developer you would always be striving to writing code in a reusable generic way regardless of the task. These are things I would personally be looking for in applicant’s submissions – anyone can write logic for a simple bowling game, I want to not only see how they write the logic but how they architect the solution
Just my two cents.
Thanks!
Adrian
Thanks for your comment, Adrian. We’re always happy to get feedback!
Regarding reusable, generic code – I just disagree with you on that point (and I guess you’re not a fan of XP
). Honestly, did you ever manage to reuse code (other than utility classes etc.) you’ve written for some specific task? Our experience here at conejct shows, that it is almost impossible to design for reuse. You just don’t know what will happen in the future. Of course I’m aware that being able to write generic code was said to be one of the advantages for OO languages. But reality showed that this was just wishful thinking.
I know that interfaces have their good sides, too, and sure, I use them if appropriate. I simply don’t understand, what the advantage of “class Ball implements IBall” is, with IBall and Ball having exactly the same set of public methods.
And of course we also look for the beauty of the code we review, not only whether the logic is correct. Basically, that’s what this blog is about.
I know what you mean; of course there is always over engineering, I’m probably guilty of that as much as the next guy :p (or girl!
)
It’s true we can’t always write generic code but we generally do a lot of code sharing in my team, by that I mean we have a very large repository of code ranging from simple utilities to large frameworks, I definitely agree with you that sometimes we tend to overkill somethings and create generic code that is never used and definately creating an interface for every class is just mindless, but there is always the ‘what if’.
So, we don’t have to necessarily design for reuse, it’s more of the ability to recognize certain patterns occurring and extracting the logic wherever possible. Generally If i see the pattern i’ll always try to extract even if i think it may never be used… for an extra half an hour spent re factoring something It may be helpful in the future – or it may not
To quote just one example, in my our team, we often have some requirement for a realtime GUI, generally fetching and processing data off some messaging interface, the views change, the processing rules change and the messaging interface changes but there is always a pattern that brings them together (virtual grid, message source, data view, UI view, UI view definition etc etc) The second time I had this kind of requirement I simply extracted the commonalities into a framework, gave it a name, stuck it into a repository and now we use it throughout many of our applications. Not only does it save time (yeah I’m a fan of XP
) but it also makes our applications more extensible as they all follow the same pattern. Of course this is just one example and I guess it’s all very subjective.
Thanks for taking the time to listen to my ranting and sorry for the long post!! It’s interesting to see a site like this, I wish my company took their developers so seriously
Adrian