Good practices for naming interfaces and implementations and placing them into packages

Question

I'm mostly speaking about Java and classical OOP. Say I'm using DAO pattern. So I create interfaces like CustomerDao, AccountDao and others. I would place then into org.example.dao package:

org.example.dao.CustomerDao
org.example.dao.AccountDao
...

This all seems good to me so far. Then I create implementations for these interfaces. Here rises my first question: How do I name them? One practice that I have seen is to use *Impl postfix like CustomerDaoImpl. Or perhaps the name should reflect the nature of the implementation, e.g. AccountDatabaseDao or DatabaseBasedAccountDao? Or may be the name should be left intact and then the package would describe the nature of these implementations? If you suggest one or another way, then where should those implementations be placed? A separate package (what naming logics?) or the same package?

Perhaps a dupe of: http://stackoverflow.com/questions/541912/interface-naming-in-java — Tim Reddy, Jun 01 '11 at 13:12

Thomas Jung · Accepted Answer · 2011-06-01T13:28:52.667

There are two camps: functional and technical naming.

The one like:

org.example.customer
org.example.account

The other like:

org.example.dao
org.example.service

I personally like to have the interface and the implementations in one spot and make only the interface public and to package by functionality as the packages have a higher cohesion this way.

With growing size you can still split the packages in for example org.example.customer.dao, org.example.customer.service and org.example.customer.ui. (Technically this is the same as org.example.dao.customer.dao, org.example.service.customer and org.example.ui.customer as Java packages are not nested.)

For your example I'd start with:

org.example.customer.CustomerDao
org.example.customer.DatabaseCustomerDao (package private)
org.example.account.AccountDao
org.example.account.DatabaseAccountDao (package private)

To make the implementation package private you need a factory to create the instances. If you're using DI. The DI-framework implements the factory for you and you can inject the instances in the users classes that depend only on the interface contract.

I also prefer to see the package used as a functional hierarchy instead of a class type one. — Robin, Jun 01 '11 at 13:47

score 1 · Answer 2 · answered Jun 01 '11 at 13:18

There are some who do

src
    org
        companyname
            dao
                impl

and have in impl e.g.

import org.companyname.dao.UserDao;

public class MySQLUserDAO implements UserDao;

or

src
    org
        companyname
            dao


import org.companyname.dao.UserDao;

public class UserDaoImpl implements UserDao;

The reason I like the first option is that you browse the impl folder to place the DAO implementation of the interface. It's neater.

score 0 · Answer 3 · answered Jun 01 '11 at 13:12

I'm not sure there is an established best practice for this. Generally we use sub-packages depending on how we implemented.

For example: The interface may be com.company.product.dao.ExampleDAO, and (if we were using MyBATIS) the implementation would be in: com.company.product.dao.mybatis.ExampleDAOMyBatis

I don't know if that's the best way of doing it but I think consistency here is more important than doing it the 'best' way - i.e. whichever scheme you pick, make sure that you stick to it throughout your codebase.

score 0 · Answer 4 · answered Jun 01 '11 at 13:15

This is all up to you.

Everything that you have listed are viable solutions to your problem, and you wouldn't be the first to do any of them.

That said, I prefer to keep the naming of the Class as the biggest descriptor:

public interface AccountDao {}

public class MySqlAccountDao implements AccountDao {}

I would place both in org.company.dao

Good practices for naming interfaces and implementations and placing them into packages

4 Answers4