4

I'm creating a new web application which will use a bunch of Data Access Object(DAO) classes for doing CRUD operations on the data. I know I should write java interfaces when I have external users/applications using my DAO classes. But if there is no such need do you think I should still write the interfaces? I'll be injecting DAO classes in to the Spring Controller(I'm using Spring MVC) classes using spring.

Orson
  • 14,981
  • 11
  • 56
  • 70
Srini Kandula
  • 981
  • 2
  • 18
  • 47

6 Answers6

9

NOTE THAT : You should always try to separating the Interface from the Implementation. This will give you more control to the other layers, using this DAO layer.

But, As you know an interface gives you more abstraction, and makes the code more flexible and resilient to changes, because you can use different implementations of the same interface without changing its client. Still, if you don't think your code will change, or (specially) if you think your abstraction is good enough, you don't necessarily have to use interfaces

In other words: interfaces are good, but before making an interface for every class think about it

Vijay Shanker Dubey
  • 4,308
  • 6
  • 32
  • 49
  • If one creates interfaces for DAOs/repositories, how do would you deal with entities? For example, if WidgetDaoImpl (which implements the interface WidgetDao) does CRUD operations on Widget objects, the interfaces and entities reside in different modules (e.g. "api" and "domain", respectively). It wouldn't make sense for the module api to have a dependency on domain, so how would you reconcile that? Thanks. – J. Lin Jan 30 '13 at 01:34
8

Yes, you should. Your classes that use them should rely on the interfaces only. This enables you to easily initialize the client classes with fake implementations of your DAOs in order to test those classes, among other things. If you just use a concrete class, then the clients of your DAOs will depend directly on that single (database accessing) implementation and be very difficult to test.

The ease of making classes rely only on interfaces for services they depend on is one of the main strengths of dependency injection and you'd be doing yourself and your application a disservice by not taking advantage of it.

ColinD
  • 108,630
  • 30
  • 201
  • 202
  • 1
    @ ClinD : You can provide different implementation for testing purpose without using interfaces. Only thing that should be abstract out in the Interface is, The important methods client layer interactions. – Vijay Shanker Dubey Dec 21 '10 at 21:31
  • @Vijay: I'm not really sure what you're saying there. If a class has a dependency that is a concrete class, the best that can be done to provide a different implementation is to create a subclass of that class (if that's possible at all) and override methods (if it allows you). You still may well be tightly coupled to some of the implementation of that class. – ColinD Dec 21 '10 at 21:35
  • Yes you are right about tight coupling, That will be tight coupled. But, Tight coupling is not a BAD thing at all always. Lowered coupling between classes will enables you to change implementations of dependencies at will. but you have to care about the cost of performance and maintenance. – Vijay Shanker Dubey Dec 21 '10 at 22:41
  • @Vijay: Performance should not be a factor in choosing to use an interface for something _at all_. I don't really see how it would make maintenance more difficult either. And I definitely don't see how tight coupling to a class that itself is tightly coupled to a slow external resource like a database can be anything but bad. – ColinD Dec 21 '10 at 22:53
  • My personal feeling about he issue is if you know, you will be spending a lot of time in maintenance, you can design loosely coupled classes as much as you want . BUT, If, however, you won't be doing that much maintenance, then loose coupling is a waste of time. In other words, if you can guarantee that maintenance will not be an issue, then couple tightly. But, personally, I've never been able to guarantee that. – Vijay Shanker Dubey Dec 21 '10 at 23:00
3

The biggest reason you should write interfaces for your DAO's (Repositories?) is so that you can easily build mocks (or use a mocking framework) to unit test anything which has a dependency ON the DAO.

Even if you're not doing unit testing, it is still a good design practice to follow DIP

Besides, how long does it really take to "right click=>Extract interface" inside of any modern IDE?

Brook
  • 5,949
  • 3
  • 31
  • 45
2

I disagree with Colour Blend. Basically my opinion is: anything that gets injected by spring should be backed (and referenced) by an interface.

Sean Patrick Floyd
  • 292,901
  • 67
  • 465
  • 588
2

Common approach when designing API for external clients is to create interfaces, not classes.

This way client will know only about contract of API which should be explicitly stated in interface javadocs and there will be no dependency on implementation details you choose.

Plus, you will be able to test clients of your API in JUnit, by providing mock implementations of your API, which would be harder if you not using interfaces.

Victor Sorokin
  • 11,878
  • 2
  • 35
  • 51
1

I don't think you should. You'll just burn up your time. Create them only if it is necessary.

Orson
  • 14,981
  • 11
  • 56
  • 70
  • @Pangea: What do you mean by valid? If you mean "the OP _could_ follow this suggestion", then yes. But it wouldn't be a good idea, particularly with DAOs, and would largely defeat one of the main advantages of using dependency injection in the first place. – ColinD Dec 21 '10 at 21:34
  • U have a point too as Colour but not everything need to be injected. – Aravind Yarram Dec 21 '10 at 21:40
  • @Pangea: Certainly not everything needs to be injected, nor does everything need to have an interface. But this question is specifically about DAOs, which are the types of services that should be injected and should definitely be put behind interfaces lest the rest of the system depend directly on their implementation and the database they talk to, etc. – ColinD Dec 21 '10 at 21:49
  • I disagree a bit. DAO's reside behind a service layer that would co-ordinate orchestration and trans demarcation. The point is that Colour Blend also has a valid point and doesn't deserve a down vote ;-) – Aravind Yarram Dec 21 '10 at 21:51
  • 2
    And how does one unit test the service layer in isolation without a dependency on persistence? By defining a contract/interface for your DAO, you can unit test the orchestrations which the service layer does between the persistence, mapper, entities etc. – Brook Dec 21 '10 at 21:53
  • @Brook - this is subjective and so is Colour's answer. The whole point is that he doesn't deserve a down vote ;-) – Aravind Yarram Dec 21 '10 at 21:55
  • @Pangea: The stated goal of SO is for Enthusiast programmers to get answers. To me that means people that are interested in doing things "right", not "quick". I don't see how "it takes more time therefore it's bad" is constructive. – Brook Dec 21 '10 at 21:59
  • @Pangea: I don't agree with you on what should and shouldn't get a downvote. Obviously there are questions where an answer may be unequivocally wrong, and those _should_ get down votes (whether they do or not is another story). Many practices in programming, however, can't be said to be _wrong_ in an absolute sense, but they're still bad. I don't want people taking this advice (which, however it was intended, amounts to "who needs interfaces?") so I'm going to downvote it. – ColinD Dec 21 '10 at 22:01
  • his time comment might not be appropriate but "Create them only if it is necessary" is perfectly valid. Do not over use DI ;-) – Aravind Yarram Dec 21 '10 at 22:03