DEV Community

Cover image for Code Smell 25 - Pattern Abusers

Code Smell 25 - Pattern Abusers

Maxi Contieri
Learn something new every day. - I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Originally published at Updated on ・2 min read

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 {
Enter fullscreen mode Exit fullscreen mode


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 {
Enter fullscreen mode Exit fullscreen mode


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

Discussion (0)