Does anybody recognize any pattern/antipattern in attached class diagram?

Question

Short description: I have a doubt whether it's normal that AbstractCrudDaoImpl implements both interface and abstract class which are inherited from the same parent (ReadOnlyDao).

Answer 1

Unless you have some special method defined in AbsractReadOnlyDaoImpl which is not in the ReadOnlyDao interface, that specific inheritance is pretty much useless.

Otherwise, looks fine.

Answer 2

You could split this question into two:

• Is it normal and meaningful to have one inteface that derives from another interface?
• Is it normal to have both an abstract class and an interface that models the same concept?

The first question is easy to answer: yes, this makes sense in situations where you have some classes that only requires the 'core' interface, but other classes that deal with the richer interface.

The other question I've previously dealt with here.

Answer 3

The design seems very reasonable to me.

By looking at your class diagram, I was able to get a clear idea about each participant. I think that's a good sign - it means there's a clear separation of roles.

The fact that CrudDao extends ReadOnlyDao makes perfect sense to me. Read-write operations are a superset of read-only operations; if you can do something with a read-only interface, you should be able to do it with a read-write interface as well - which is exactly what inheritance achieves.

Answer 4

seems weird. Should CrudDao access ReadOnlyDao instead of AbstractReadOnlyDao? At first it seemed weird AbstractReadOnlyDao is accessing AbstractReadOnlyDaoImpl but on second look it seems ok.

Answer 5

I would take exception to the name ReadOnlyDao - it implies that anything that implements it is also read only, which is clearly untrue.

I suggest changing it to ReadableDao. Ditto for AbstractReadableDaoImpl.