Tight Coupling

Description

What does it look like?

• A class (e.g., OrderService) directly instantiates or calls another class (e.g., EmailService, InventoryService)
• Due to strong dependencies, any change to a dependency immediately affects the caller
• Difficult to substitute mocks or stubs during testing
• Readability, flexibility, and testability suffer

Why is it a problem?

• Every addition or modification requires changes in the original class, resulting in high maintenance cost
• Leads to a state where “it works, so don’t touch it,” accumulating technical debt
• The class ends up with multiple responsibilities, resulting in poor separation of concerns

Bad Example of the Anti-pattern

TypeScript

class Mailer {
  send(email: string, content: string) {
    console.log(`送信しました: ${email} → ${content}`);
  }
}

class UserService {
  private mailer: Mailer;

  constructor() {
    this.mailer = new Mailer(); // ← クラス内で直接生成（密結合）
  }

  notifyUser(email: string) {
    const content = "ようこそ！";
    this.mailer.send(email, content); // ← Mailer の存在を知りすぎている
  }
}

PHP

<?php

class Mailer {
  public function send(string $email, string $content): void {
    echo "送信しました: {$email} → {$content}\n";
  }
}

class UserService {
  private Mailer $mailer;

  public function __construct() {
    $this->mailer = new Mailer(); // ← 密結合：直接生成
  }

  public function notifyUser(string $email): void {
    $content = "ようこそ！";
    $this->mailer->send($email, $content); // ← Mailer の存在を知りすぎている
  }
}

// 利用例
$service = new UserService();
$service->notifyUser("user@example.com");

Python

class Mailer:
    def send(self, email: str, content: str):
        print(f"送信しました: {email} → {content}")

class UserService:
    def __init__(self):
        self.mailer = Mailer()  # ← 密結合：直接生成

    def notify_user(self, email: str):
        content = "ようこそ！"
        self.mailer.send(email, content)  # ← Mailer に強く依存

# 利用例
service = UserService()
service.notify_user("user@example.com")

Issues:

• UserService is tightly coupled to Mailer, and locked into its specific implementation
• Difficult to switch to another mail system (e.g., external API, mock service)
• If requirements change (e.g., logging mailer, switching to SMS), changes must be made to UserService
• Even if you want to share the Mailer logic, each instance is created separately, making it hard to centralize configuration

Refactoring by Pattern

Design patterns that can address this

Pattern	Overview	Main Refactoring Approach
Observer	Delegate processing via event notification	Use external registration for loose coupling
Mediator	A central coordinator mediates communication	Reduce many-to-many dependencies to 1-to-1
Dependency Injection (DI)	Inject dependencies from outside for easy replacement	Improves testability and extensibility