Don't turn collaborators into permanent roommates Don't turn collaborators into permanent roommates TL;DR: You should avoid storing stateless utility classes as instance variables initialized with new. 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 Hardcoded dependencies Testing difficulties High coupling coupling Hidden side effects Rigid design Misleading intent Premature Optimization Stack clutter Solutions 😃 Use dependency injection
Pass as parameter
Use static methods
Inline the logic
Use local variables
Inline object creation Use dependency injection Pass as parameter Use static methods Inline the logic Use local variables Inline object creation Refactorings ⚙️ https://hackernoon.com/refactoring-024-replace-global-variables-with-dependency-injection?embedable=true 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-030-how-to-avoid-accidental-redundancy?embedable=true https://hackernoon.com/refactoring-007-the-refactor-that-reveals-missing-concepts?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);
  }
} 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);
  }
} 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);
    }
  } // Simpler but coupled
 class UserProcessor {
    constructor() {
      // Empty
    }

    process(data: any) {
      return new MockDataProvider().format(data);
    }
  } Detection 🔍 Look for the new keyword inside constructors. new 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 Premature Optimization Level 🔋 [X] Beginner Why the Bijection Is Important 🗺️ Software should mimic a MAPPER of the real world. MAPPER 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. bijection 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. new 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 Remember: AI Assistants make lots of mistakes Suggested Prompt: remove the cached attribute Suggested Prompt: remove the cached attribute Without Proper Instructions 📵 ChatGPT
Claude
Perplexity
Copilot
You
Gemini
DeepSeek
Meta AI
Grok
Qwen ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot You You Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen With Specific Instructions 👩‍🏫 ChatGPT
Claude
Perplexity
Copilot
You
Gemini
DeepSeek
Meta AI
Grok
Qwen ChatGPT ChatGPT Claude Claude Perplexity Perplexity Copilot Copilot You You Gemini Gemini DeepSeek DeepSeek Meta AI Meta AI Grok Grok Qwen Qwen 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/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 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 https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true Disclaimer 📘 Code Smells are my opinion. opinion Credits 🙏 Photo by Possessed Photography on Unsplash Possessed Photography Unsplash Coupling is the enemy of change Coupling is the enemy of change Rich Hickey Rich Hickey https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true 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 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Unsplash

AI Coding Tip 015 - Force the AI to Obey You

AI Coding Tip 014 - One AGENTS.md Is Hurting Your AI Coding Assistant

Buy My Book

Code Smell 319 - Hardcoded Stateless Properties

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

10 Predictions About the Future of Finance

Why More Code Doesn’t Necessarily Mean More Progress

Walk-Forward Optimisation in Python, Step by Step

Why Modular Architecture Makes AI Coding Tools Work Better

Code Smell 240 - Dead Store Code

Comparing XML and Compose Rendering Speed at Deep and Wide Nesting

10 Predictions About the Future of Finance

Why More Code Doesn’t Necessarily Mean More Progress

Walk-Forward Optimisation in Python, Step by Step

Why Modular Architecture Makes AI Coding Tools Work Better

Code Smell 240 - Dead Store Code

Comparing XML and Compose Rendering Speed at Deep and Wide Nesting

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps