Skip to main content
added 474 characters in body; edited title
Source Link

Extending "base" classes Convenience inheritance

Is extendingSometimes, you inherit from a "base" class that defines the semantics of your type (often abstractShapeEllipseCircle). Other times, you inherit simply because it's convenient to do so.

  1. A superclass may have protected members you want to get access to.
  2. It may implement some methods of an interface that you want your class to implement – now, you have fewer methods to be bothered about.
  3. It may implement an interface's only method in a way that covers some generic aspects of it and then delegates to its own abstract method that is supposed to do a smaller, easier, implementation-specific part.

Is such "convenience inheritance" an anti-pattern?

Here's argument against that.

Since you can't "hide" your class's supertypes from your class's clients, its entire type hierarchy is part of its API, including the "base" class. Clients can store your implementation in a variable of the abstract "base" type. Good luck changing your supertype after thatlater.

Here's an example. There's a BaseDao class in our codebase. It's not technically abstract but, to the best of my knowledge, it is not directly instantiated anywhere, so you can say it's effectively abstract. Specific DAOs extend from it, inheriting protected convenience methods, for example findWithAppSql().

Extending "base" classes

Is extending a "base" class (often abstract) an anti-pattern?

Since you can't "hide" your class's supertypes from your class's clients, its entire type hierarchy is part of its API, including the "base" class. Clients can store your implementation in a variable of the abstract "base" type. Good luck changing your supertype after that.

Here's an example. There's a BaseDao class in our codebase. It's not technically abstract but, to the best of my knowledge, it is not directly instantiated anywhere, so you can say it's effectively abstract. Specific DAOs extend from it, inheriting protected convenience methods, for example findWithAppSql().

Convenience inheritance

Sometimes, you inherit from a class that defines the semantics of your type (ShapeEllipseCircle). Other times, you inherit simply because it's convenient to do so.

  1. A superclass may have protected members you want to get access to.
  2. It may implement some methods of an interface that you want your class to implement – now, you have fewer methods to be bothered about.
  3. It may implement an interface's only method in a way that covers some generic aspects of it and then delegates to its own abstract method that is supposed to do a smaller, easier, implementation-specific part.

Is such "convenience inheritance" an anti-pattern?

Here's argument against that.

Since you can't "hide" your class's supertypes from your class's clients, its entire type hierarchy is part of its API, including the "base" class. Clients can store your implementation in a variable of the abstract "base" type. Good luck changing your supertype later.

Here's an example. There's a BaseDao class in our codebase. Specific DAOs extend from it, inheriting protected convenience methods, for example findWithAppSql().

added 7 characters in body; edited title
Source Link

Extending abstract "base" classes

Is extending an abstracta "base" class (often abstract) an anti-pattern?

Extending abstract "base" classes

Is extending an abstract "base" class an anti-pattern?

Extending "base" classes

Is extending a "base" class (often abstract) an anti-pattern?

Post Reopened by Sergey Zolotarev, Doc Brown, CPlus
Keep out the meta-commentary
Source Link
CPlus
  • 1.2k
  • 1
  • 13
  • 36

I wanted to keep the question general and avoid discussions that are too specific and hence less useful (both for me and the general public). However, Doc Brown forced my hand. Let's be honest, in my particular case, it's pretty clear what should be done (even though it's very costly and unlikely to be actually done).

I wanted to keep the question general and avoid discussions that are too specific and hence less useful (both for me and the general public). However, Doc Brown forced my hand. Let's be honest, in my particular case, it's pretty clear what should be done (even though it's very costly and unlikely to be actually done).

added 2265 characters in body
Source Link
Loading
added 2265 characters in body
Added to review
Source Link
Loading
Post Closed as "Needs details or clarity" by gnat, Doc Brown, Peter K.
deleted 15 characters in body
Source Link
Loading
added 213 characters in body
Source Link
Loading
Source Link
Loading