This story on HackerNoon has a decentralized backup on Sia.
Transaction ID: mZwfB-N58iWtJZqVc9FigZFOTe0xa53u_vLfKclSGIA
Cover

Code Smell 319 - Hardcoded Stateless Properties

Written by @mcsee | Published on 2026/4/12

TL;DR β€”
AI can easily detect this smell without explicit instructions. When you show AI a class withΒ newΒ keywords in the constructor, it recognizes the pattern as hardcoded coupling. AI identifies that stateless utility classes should be injected rather than instantiated internally. The detection is straightforward because the pattern is syntactically obvious and semantically harmful.

Don't turn collaborators into permanent roommates

TL;DR: You should avoid storing stateless utility classes as instance variables initialized with new.

Problems πŸ˜”

  • Hardcoded dependencies
  • Testing difficulties
  • High coupling
  • Hidden side effects
  • Rigid design
  • Misleading intent
  • Premature Optimization
  • Stack clutter

Solutions πŸ˜ƒ

  1. Use dependency injection
  2. Pass as parameter
  3. Use static methods
  4. Inline the logic
  5. Use local variables
  6. Inline object creation

Refactorings βš™οΈ

https://hackernoon.com/refactoring-024-replace-global-variables-with-dependency-injection?embedable=true

https://hackernoon.com/refactoring-030-how-to-avoid-accidental-redundancy?embedable=true

https://hackernoon.com/refactoring-007-the-refactor-that-reveals-missing-concepts?embedable=true

Context πŸ’¬

Hardcoding a stateless class in the constructor creates permanent coupling.

Even if the class is cheap to instantiate, you lose the ability to swap it.

Stateless objects shouldn't be part of the object's internal state.

You confuse readers by making a tool look essential to the object's identity.

It makes testing harder because you can't mock the hardcoded dependency.

Sample Code πŸ’»

Wrong 🚫

class UserProcessor {
  private provider: MockDataProvider;

  constructor() {
    // You hardcode the dependency here.
    // This makes the class harder to test.
    this.provider = new MockDataProvider();
  }

  process(data: any) {
    return this.provider.format(data);
  }
}

Right πŸ‘‰

interface DataProvider {
  format(data: any): any;
}

class UserProcessor {
  // You inject the dependency via constructor.
  // Now you can swap it or mock it easily.
  constructor(private readonly provider: DataProvider) {}

  process(data: any) {
    return this.provider.format(data);
  }
}
// Simpler but coupled
 class UserProcessor {
    constructor() {
      // Empty
    }

    process(data: any) {
      return new MockDataProvider().format(data);
    }
  }

Detection πŸ”

Look for the new keyword inside constructors.

Watch for private properties instantiated directly in the constructor rather than passed as parameters.

Most linters flag this pattern automatically when you create instances and assign them to private fields.

Tags 🏷️

  • Premature Optimization

Level πŸ”‹

[X] Beginner

Why the Bijection Is Important πŸ—ΊοΈ

Software should mimic a MAPPER of the real world.

In reality, a worker might use a tool to complete a task.

The tool is not a permanent physical attachment to the worker.

When you refactor to use dependency injection, you respect the bijection by treating collaborators as external entities, not internal state.

This keeps your simulation flexible and accurate.

AI Generation πŸ€–

AI generators frequently create this smell.

They often suggest code that just works by instancing dependencies directly in the constructor to save time.

AI Detection 🧲

AI can easily detect this smell without explicit instructions.

When you show AI a class with new keywords in the constructor, it recognizes the pattern as hardcoded coupling.

AI identifies that stateless utility classes should be injected rather than instantiated internally.

The detection is straightforward because the pattern is syntactically obvious and semantically harmful.

Try Them! πŸ› 

Remember: AI Assistants make lots of mistakes

Suggested Prompt: remove the cached attribute

Without Proper Instructions πŸ“΅

With Specific Instructions πŸ‘©β€πŸ«

Conclusion 🏁

Storing stateless dependencies as instance variables makes your code rigid.

When you inject these dependencies instead, you improve testability and keep your objects focused on their true purpose.

Relations πŸ‘©β€β€οΈβ€πŸ’‹β€πŸ‘¨

https://hackernoon.com/code-smell-06-trying-to-be-a-clever-programmer?embedable=true

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-iv-7sc3w8n?embedable=true

More Information πŸ“•

https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true

Disclaimer πŸ“˜

Code Smells are my opinion.

Credits πŸ™

Photo by Possessed Photography on Unsplash


Coupling is the enemy of change

Rich Hickey

https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true


This article is part of the CodeSmell Series.

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

[story continues]


Written by
@mcsee
I’m a sr software engineer specialized in Clean Code, Design and TDD Book "Clean Code Cookbook" 500+ articles written

Topics and
tags
code-smells|refactoring|common-code-smells|stateless-properties|hardcoded-dependencies|code-refactoring|hardcoding|stateless-objects
This story on HackerNoon has a decentralized backup on Sia.
Transaction ID: mZwfB-N58iWtJZqVc9FigZFOTe0xa53u_vLfKclSGIA