CODEWITHSUNDEEP
javaoopdesign-patterns
ktm5124
ktm5124

Reputation: 12123

Is this a DAO manager pattern? What are the appropriate class and interface names?

I have an interface, SomethingDao, and an implementing class, SomethingDaoImpl. The interface consists of only 11 methods, but each method requires one or more complex SQL queries.

I broke up the implementing class into several smaller classes, let's call them Helper1, Helper2, Helper3, ... HelperN for lack of better names. The SomethingDaoImpl has an instance of each, and routes method calls to each.

public class SomethingDaoImpl implements SomethingDao {
    private Helper1 helper1;
    private Helper2 helper2;
    private Helper3 helper3;
    // ...
    private Helper8 helper8;

    public List<X> getX(...) {
        return helper1.getX();
    }

    public List<Y> getY(...) {
        return helper2.getY();
    }


    public List<X> getDetailedX(...) {
        List<X> ds = getX(...); 

        helper6.addTo(ds);
        helper7.addTo(ds);
        helper8.addTo(ds);

        return ds;
    }
}

Is there a name for this technique? Where a complex DAO has several "worker" bees that do all the work for it, and it just manages them?

Is it simply the DAO manager pattern, where Helper1, Helper2, Helper3 are the DAO objects? I'm interested in the proper naming conventions, so in this case I would rename SomethingDaoImpl to SomethingDaoManager, and Helper would become HelperDao.

I have also seen the name 'Service' used in its place, in which case the SomethingDao interface would be renamed SomethingService, and the worker-bee classes would carry DAO at the end of their names.

Thanks... I think I am just looking for the naming conventions, and design pattern, associated with this scenario. I would like the implementation to be as clear as possible, and having names that suggest the pattern I am using would be very helpful.

Upvotes: 2

Views: 1624

Answers (2)

davioooh
davioooh

Reputation: 24666

If you have only 11 methods in your DAO class is very strange that you need so many helper classes to implement them.

The question is, why your SQL queries are so complex?

Be sure to creare a distinct DAO interface/class for each entity/table in your DB/data source. This will help you to have simpler DAO classes and reduce tight coupling.

UPDATE

As you wrote in the comment, I think it's more correct to consider your SomethingDao as a facade interface for a complex logic. (This article is very clear about it).

So you could create a different DAO for each entity and use this classes in your SomethingDaoImpl, implementing the facade interface.

If you want to follow some kind of naming convention, you could rename your classes simply in SomethingFacade and SomethingFacadeImpl.

Upvotes: 1

MikeSW
MikeSW

Reputation: 16348

IMO that code is the 'bad code' pattern, more exactly tight coupled code. 8 helpers are LOT and it's clealry a badly designed object. I know this is java and probably you don't have something like c# extension methods which are ideally for helpers, so I think the properly way is to use Dependency Injection via a DI Container.

Every object needing a DAO or a Service would get those as abstract dependencies, mostly as constructor arguments. 

public class MyObject
{
    public MyObject(ISomeService serv,IRepository repo){}
}

THe point is, to use ONLY the objects that are relevant for the context and the code would take those as dependencies. I highly doubt it you might need 8 helpers for anything. If that's the case, then that code does way to much and needs to be redesigned.

Upvotes: 1

Related Questions