# Code Smell 43 - Concrete Classes Subclassified

*Inheritance. Concrete classes. Reuse. A fantastic mix up.*

# Problems

- Bad Models

- Coupling

- [Liskov Substitution](https://en.wikipedia.org/wiki/Liskov_substitution_principle) Violation

- Method overriding

- [Mapper](https://maximilianocontieri.com/what-is-wrong-with-software) fault

# Solutions

1. Subclasses should be specializations.

2. Refactor Hierarchies.

3. Favor Composition.

4. Leaf classes should be concrete.

5. Not leaf classes should be abstract.

# Sample Code

## Wrong

%[https://gist.github.com/mcsee/9780cd7772afddbc8356bab8aa5eabed]

## Right

%[https://gist.github.com/mcsee/3edd25966d27541140a3e4672f5e9b3c]

# Detection

Overriding a concrete method is a clear smell. We can enforce these policies on most linters.

Abstract classes should have just a few concrete methods. We can check against a predefined threshold for offenders.

# Tags

- Composition

# Conclusion

Accidental sub-classification is the first obvious advantage for junior developers. 

More mature ones find composition opportunities instead. 

Composition is dynamic, multiple, pluggable, more testable, more maintainable and less coupled than inheritance.

Only sub-classify an entity if it follows the relationships *behaves like*.

After sub-classing the parent class should be abstract.

# Relations

%[https://maximilianocontieri.com/code-smell-11-subclassification-for-code-reuse]

# More info
 
%[https://en.wikipedia.org/wiki/Composition_over_inheritance]

* * *

> Software is a gas; it expands to fill its container.

_Nathan Myhrvold_

%[https://mcsee.hashnode.dev/software-engineering-great-quotes]

* * *

This article is part of the CodeSmell Series.

%[https://mcsee.hashnode.dev/how-to-find-the-stinky-parts-of-your-code]