Code Smell 25 - Pattern Abusers

Code Smell 25 - Pattern Abusers

Maxi Contieri
·Nov 15, 2020·

2 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Patterns are awesome. With great powers comes great responsibility.

TL;DR: Don't abuse patterns.


  • Over Design

  • Readability


  1. Measure the tradeoff of patterns usage.

  2. Create solutions based on real world names (essential) over architecture (accidental).

  3. Choose good names.

  4. User MAPPER technique to find bijection real entities.

Sample Code


public final class FileTreeComposite {
    //name should be inferred from behaviour

public final class DateTimeConverterAdapterSingleton {

public final class PermutationSorterStrategy {

public final class NetworkPacketObserver {

public final class AccountsComposite {
public final class FileSystem {
    // These names map 1:1 to real world concepts

public final class DateTimeFormatter {

public final class BubbleSort {

public final class NetworkSniffer {

public final class Portfolio {


It would be very difficult to create automatic detection rules.

A class name with more than one pattern on it, is a warning.


  • Abuser

  • Naming


Chose when to apply a pattern solution. You are not smarter for using too many patterns. You are smart if you choose the right opportunity for everyone.


More Info


Photo by Nathan Dumlao on Unsplash

When you have a hammer, every problem looks like a nail.

This article is part of the CodeSmell Series.

Last update: 2021/07/09

Share this


Technical Opinions are my own. I don't have the revealed truth.

Software Design is a creative activity. These are hints and not rigid rules.

I write on BackEnd Business Systems and OOP Design. My advice/experience might not suit other systems.

You can write me at info(at)