DEV Community

loading...
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 maximilianocontieri.com Updated on ・2 min read

Patterns are awesome. With great powers comes great responsibility.

TL;DR: Don't abuse patterns.

Problems

  • Over Design

  • Readability

Solutions

  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

Wrong

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

Right

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

Detection

It would be very difficult to create automatic detection rules.

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

Tags

  • Abuser

  • Naming

Conclusion

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.

Relations

More Info

Credits

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)