Return to Answer

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ). Even with two dimensions, this would lead to an explosion of classes, let alone the fact it now becomes unclear whether PersonPostgreSQLDAO should inherit from PersonDAO, from PostgreSQLDAO or just from BaseDAO.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance. Or, you can do this the other way round: DBMS may have generic methods which work on BaseDAO objects, or each DBMS entry may provide a list of loaded (cached) DAO objects.

So this all boils down to use inheritance for one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will not cause too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, as I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class, or making slight adjustments to those classes.

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ). Even with two dimensions, this would lead to an explosion of classes, let alone the fact it now becomes unclear whether PersonPostgreSQLDAO should inherit from PersonDAO, from PostgreSQLDAO or just from BaseDAO.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance. Or, you can do this the other way round: DBMS may have generic methods which work on BaseDAO objects, or each DBMS entry may provide a list of loaded (cached) DAO objects.

So this all boils down to use inheritance for one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will not cause too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, as I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class, or making slight adjustments to those classes.

Addendum: here is an article from 2015 which explains the idea of inheritance and dimensions well: Composition vs. Inheritance: How to Choose?.

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ), and has to duplicate a lot of code.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance. Or, you can do this the other way round: DBMS may have generic methods which work on BaseDAO objects, or each DBMS entry may provide a list of loaded (cached) DAO objects.

So this all boils down to use inheritance for one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will not cause too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, as I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class.

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ). Even with two dimensions, this would lead to an explosion of classes, let alone the fact it now becomes unclear whether PersonPostgreSQLDAO should inherit from PersonDAO, from PostgreSQLDAO or just from BaseDAO.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance. Or, you can do this the other way round: DBMS may have generic methods which work on BaseDAO objects, or each DBMS entry may provide a list of loaded (cached) DAO objects.

So this all boils down to use inheritance for one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will not cause too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, as I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class, or making slight adjustments to those classes.

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ), and has to duplicate a lot of code.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance.

So this all boils down to use inheritance for *one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will cause not too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, what I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class.

IMHO implementation inheritance is not an anti-pattern in general.

There are too many examples where this works well enough to ban this kind of inheritance dogmatically. You presented a few examples where the convenience wins over other aspects, and I could extend the list by several examples by myself, hence it should be clear that we talk about a trade-off, not a no-go.

So under which circumstances is this kind of inheritance ok, and when not?

I think the most important aspect here is to stick to a single dimension for a single inheritance tree.

What does that mean? It means, for example, not to mix a domain model dimension with technical dimensions.

For example, let's take your BaseDAO. Using inheritance for domain concepts, you can have classes like PersonDAO, DoctorDAO, or PrescriptionDAO, modeling the domain dimension.

But now lets assume you want to support different database systems, and you want special DAO classes for PostgreSQL, Oracle and maybe MongoDB. Then you create PostgreSQLDAO, OracleDAO and MongoDBDAO, using inheritance for a technical dimension. This, however, mixes up badly with domain inheritance, one would need to combine each of the domain classes with each of the DBMS specific classes (like a PersonPostgreSQLDAO etc. ), and has to duplicate a lot of code.

So how do we solve this issue? We can, for example, stick with the domain dimension for the DAOs, model the DBMS hierarchy separately (for example, with a base class DBMS and subclasses PostgreSQLDBMS, OracleDBMS and MongoDBMS), and then let BaseDAO hold a reference to a DBMS instance. A BaseDAO method like findWithAppSql may then delegate any DBMS specific work to the specific DBMS instance. Or, you can do this the other way round: DBMS may have generic methods which work on BaseDAO objects, or each DBMS entry may provide a list of loaded (cached) DAO objects.

So this all boils down to use inheritance for one dimension only per tree. Composition is the right tool when you need a second dimension which should behave orthogonal to the first one. As long as the design sticks to this guideline, implementation inheritance will not cause too much trouble.

Finally, I would like to mention that IMHO a class like BaseDAO (or simply DAO, as I would call it), has semantics. It classifies all subclasses as Data Access Objects of your system, which gives them a clear purpose and distinguishes them from other classes. Maybe you have other classes in mind, where the semantics isn't so clear as here - this, however, may be simply a question of finding a better name for the common base class.