Static Class Laravel Package

Product Decisions This Supports

• Enforcing architectural patterns: Adopt a strict static-class design for utility functions (e.g., StringHelper, MathUtils) to prevent accidental instantiation and encourage pure functional usage.
• Roadmap for maintainability: Phase out instantiable helper classes in legacy codebases by retrofitting them with StaticClass to align with SOLID principles (Single Responsibility, Dependency Inversion).
• Build vs. buy: Avoid reinventing static-class enforcement (e.g., __construct with throw new \RuntimeException) by leveraging this lightweight, MIT-licensed solution.
• Use cases:
  • Utility libraries: Force static usage for classes like ArrayValidator, DateFormatter.
  • Domain-specific helpers: Enforce immutability for PaymentCalculator or TaxRules to prevent stateful misuse.
  • Legacy refactoring: Convert instantiable singletons (e.g., ConfigManager) to static classes for thread safety and clarity.

When to Consider This Package

• Adopt if:

  • Your codebase has utility classes that should never be instantiated (e.g., StringUtils, Logger).
  • You prioritize design purity over flexibility (e.g., rejecting dependency injection for static helpers).
  • You’re using Laravel and want to prevent accidental instantiation of facades or service containers.
  • Your team enforces static analysis tools (e.g., PHPStan) and wants to catch violations early.

• Look elsewhere if:

  • Your architecture relies on dependency injection (e.g., Laravel’s container) for testability or mocking.
  • You need stateful behavior (use a singleton pattern or DI container instead).
  • The package’s maturity (low stars, no dependents) is a concern for mission-critical systems.
  • You prefer built-in PHP features (e.g., final class + private constructor) over a trait.

How to Pitch It (Stakeholders)

For Executives: "This package lets us enforce a cleaner codebase by preventing accidental instantiation of utility classes—reducing bugs and improving maintainability. For example, we could retroactively mark StringHelper as static, ensuring it’s used functionally (e.g., StringHelper::slugify()) rather than instantiated. This aligns with our goal of [X metric, e.g., 'reducing technical debt by 20%'] while keeping implementation lightweight."

For Engineers: *"The StaticClass trait is a drop-in solution to replace manual __construct guards. It’s ideal for:

• Utility classes (e.g., ArrayTools, DateParser) where instantiation is meaningless.
• Legacy cleanup: Converting old singletons to static classes for thread safety.
• Consistency: Enforcing static usage across the team without runtime checks.

Tradeoff: Loses DI flexibility, but gains clarity. Pair with PHPStan’s no-unused-static-methods for extra safety."*