Clear Code
  • Introduction
    • About This Book
    • Timeline
    • Software Killers
    • Billion Dollar Mistakes
    • Clear Code Overview
    • Clear Code Rules
  • Data Processing
    • Separate Data Collection And Processing
    • Create Data Models
    • Separate Use Cases
    • Data Should Be Immutable
  • Examples
    • Separate Use Cases With Data Model
  • Maintenance Cost
    • Consider the Maintenance Cost
    • The Software Exists In Time
    • Don't Feed the Monsters
  • OOP
    • Separate Data And Procedures
    • Do Not Use Inheritance
    • When To Avoid Inheritance?
    • What Is The Problem With Abstract Frameworks?
  • VARIOUS
    • The Real Single Responsibility Principle
    • The problem with Clean Code's name
    • How To Handle Warnings
    • Do Not Create Constant Collection Classes
  • Externals
    • Links
    • Quotes
    • Funny
  • Technology
    • Git Tutorials
  • Clean Code
    • Clean Code Introduction
      • Origin & Overview
      • Advanced
      • Typical Issues
    • Clean Code Outline
      • Why Clean Code?
      • Clean Code
      • Clean Code Approaches
      • Specification & Design
      • Duplication
      • Refinement & Refactoring
      • Conventions
      • Names
      • Types
      • Methods
      • Nulls and Validity Checks
      • Comments
      • Dead Code
      • Error Handling
      • Classes
      • Code Formatting
      • Unit Tests
      • Special Cases
      • Object Oriented Programming
      • General Code Smells
    • Clean Code Links
    • Clean Code TOC
    • Effective Java TOC
Powered by GitBook
On this page
  • Feature development
  • Framework development
  • Inheritance in reality

Was this helpful?

  1. OOP

What Is The Problem With Abstract Frameworks?

2016.06.19

I often find it very hard to maintain the class hierarchies we write. And I am constantly thinking about the reasons, why. Inheritance is one of the basic principles of object-oriented programming, so it may sound strange that there is a problem with it. Of course, inheritance is good but the way we use it may not be good. Let me explain it through an example.

Feature development

Imagine that you are a programmer and you have a task to implement a certain feature. What do you expect?

Specification:

  • The feature is carefully found out and discussed by one or more business analysts.

Design:

  • Prior to the coding, the solution is well planned by technical people like architects or by the developers themselves. At least verbally but possibly in written documents.

Implementation:

  • The feature is not only implemented well, but it also fulfills the requirements.

Test:

  • The implemented program is tested on at least one level but more levels are better (unit, functional, integration, etc. tests).

Usually, these steps happen in a software company.

Framework development

When you create class hierarchies to use them in the future, and to use them by other developers, then you really create a framework. Especially the presence of abstract classes shows that others have to "put their classes under this hierarchy", i.e. implement classes and methods. That is what I call a "framework".

So imagine now that you have to implement a framework. Wouldn't you expect the same conditions as in the feature development?

  • Specification

  • Design

  • Implementation

  • Testing

Yes, you would.

Inheritance in reality

And now let's see how and why programmers create class hierarchies and abstract classes in reality. They work on a certain feature and create classes for it. During the coding they might say:

"It is so generic, I extract it to a parent class."

Or, even more often they discover the similarities between some classes and they say:

"I put the equal parts into a common base class and the differences into abstract methods."

Or they may have other complex reasons including the usage of a design pattern (which is at least a more judicious approach).

But remember, this is a framework development. What about the expected conditions?

  • Specification: No

  • Design: No

  • Implementation: Yes but...

  • Testing: No

A little bit more detailed:

Specification:

  • The intention of such frameworks is always this one:

    "It will be good for the next developer / modification / sub-class / etc."

  • But unfortunately, it will not.

Design:

  • There is only an ad hoc design. The programmer has just a quick idea, which usually does not exceed the "common base class" antipattern.

  • Moreover, it does not fulfill the specification. (Remember: "It is generic." or "It will be good for the future."). Instead of that, it usually only freezes the differences between some already existing specific classes.

Implementation:

  • There is, but not in the terms of fulfilling the requirements since there are none.

Testing:

  • The developers usually test only the sub-classes, which involves more or less the code from the parent classes too. But the parent classes - especially the abstract ones - are not explicitly tested. They are not tested like any other classes with a well-defined and enclosed functionality.

Last updated 1 year ago

Was this helpful?