• Post Reply Bookmark Topic Watch Topic
  • New Topic

Benefits of custom interfaces for a small project?  RSS feed

 
S Chan
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Just a trivial question here.

I was wondering if I were going to make a one-developer small scale project myself. Is there actually any point of writing interfaces and implementing them? If so, what are the benefits?

I've heard a lot about the benefits of using interfaces, but I find using them quite tedious when I am working alone: write an interface and implement it <- twice the effort!

Writing an interface just doesn't make me learn better of the class interaction because I am the sole developer of the project so I SHOULD know very well about the class interaction, right?

If, let's say, there is exactly one implementation per interface in the project, I just thought - why don't I just directly write the solid classes out without the interface instead? Sometimes, if the design requires, I can just use abstract classes or extend existing classes when I need to. Isn't that enough?

Very often, I build many small projects myself. I aim to complete them and get them running in a few hours or in a day. So writing interfaces may mean doing something extra for no significant benefits if the project design doesn't require me to build the class/component interfacing.

I hope to hear some advice from you - especially to tell me what I think above is wrong. Thank you all in advance
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
S Chan wrote:I was wondering if I were going to make a one-developer small scale project myself. Is there actually any point of writing interfaces and implementing them? If so, what are the benefits?

Mostly flexibility.
If, let's say, there is exactly one implementation per interface in the project, I just thought - why don't I just directly write the solid classes out without the interface instead? Sometimes, if the design requires, I can just use abstract classes or extend existing classes when I need to. Isn't that enough?

No, and class hierarchies are generally frowned on these days in all but the most rigorous cases (Google "favour composition over inheritance").
And what if things change, and you do have to add a second implementation? You're now stuck with a whole pile of refactoring that you could have avoided just by writing a few extra method signatures.

Personally, I write an interface for practically every non-trivial class I write now (although, admittedly, not always first, like I should ).

Winston
 
Paul Clapham
Sheriff
Posts: 22828
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion an interface which is only going to have one implementation is unnecessary. And worse, it violates the Don't Repeat Yourself principle.

Usually you can tell pretty well if you're writing something which is only ever going to have one implementation. In this case I don't think you should write an interface for that one implementation to implement. (If you guessed wrong, then you have some work to do, but it should be less than all the extra work you have to do to declare all your methods in two different places.)

Let me give you an example. Where I work we have an application which contains a large number of examples of the Command pattern. For each command we write, there's a Command object, a Request object, and a Response object. That of course requires three interfaces (Command, Request, and Response). So far, so good, that is what interfaces are for.

However the people who wrote a lot of the commands went overboard with the interface idea. So if we have a RetrieveClientCommodities command with corresponding request and response objects, that means we have a RetrieveClientCommodities interface which is only implemented by the RetrieveClientCommoditiesBean class, a RetrieveClientCommoditiesRequest interface which is only implemented by the RetrieveClientCommoditiesRequestBean class, and a RetrieveClientCommoditiesResponse interface which is only implemented by the RetrieveClientCommoditiesResponseBean class.

And there really isn't much scope for reusing those Request and Response objects. Mostly they are closely tied to the commands which use them, so trying to reuse them with similar-looking commands adds a future risk, namely what happens when those commands weren't as similar as they looked? So we don't reuse them. This pretty much guarantees that their interfaces are going to have a single implementation. One of these days I plan to get rid of all those surplus interfaces, as they don't buy us anything but extra work.
 
Stephan van Hulst
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to admit that for small project I work on myself, I often forgo writing lots of interfaces. If I can envision reusing a type in another project or another version of the application, I will create an interface first. If I can only imagine a single use for a type that is pretty straightforward, I just write one final class without an interface. Sometimes the use of a class is really too specific for me to be bothered to write an interface.

It's interesting though, I have a very small library of classes/interfaces I wrote myself, which I reuse between projects. A big part of them had to do with I/O. I just finished writing a set of related interfaces that dealt with seekable channels (Seekable, ReadableSeekChannel, WritableSeekChannel, SeekChannel, SplitSeekChannel, FileSeekChannel). Then Java 1.7 came out and provided us with SeekableByteChannel, which did *exactly* what part of my library did.. So I refactored all my old code to use SeekableByteChannel instead, and threw most of my library out (with the exception of SplitSeekChannel, which I refactored because I don't think there's an equivalent in the existing API).

There's no real moral to the story, but I thought it was funny my interfaces became obsolete so quickly, so I thought I'd share. I guess I'm a little bit proud I designed a non-trivial set of classes of which an almost identical version later appeared in the standard API.
 
Maneesh Godbole
Bartender
Posts: 11445
18
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont think having an interface and a concrete implementation is that much of a time hog. With good IDE's like eclipse, having the base code generated, is just a few keystrokes away. In return you get the flexibility which interfaces provide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!