Anonymous Classes (PHP 7.0)
debt(d6/e3/b2/t4)
Closest to 'specialist tool catches' (d5), +1. PHPStan can detect some patterns (e.g., unused named stub classes that could be anonymous), but the decision of when to use anonymous classes vs named classes vs closures is largely a design judgment call. The detection_hints note 'automated: no', meaning no tool reliably flags misuse. Careful code review is needed to spot cases where anonymous classes should or shouldn't be used, pushing this above d5 toward d7 but not fully there since PHPStan can catch some type-related issues with anonymous class usage.
Closest to 'simple parameterised fix' (e3). The quick_fix is straightforward: replace a named single-use class with an inline anonymous class definition, or vice versa. This typically touches one or two files (the test file and possibly removing the named class file). It's a localized refactor within one component, not cross-cutting.
Closest to 'minimal commitment' (b1), +1. Anonymous classes are localized constructs — each instance is self-contained at a single call site. They don't impose structural weight across the codebase. However, they do carry a minor maintenance tax: debugging is harder (get_class returns internal identifiers), and team members need to understand the pattern. The reach is minimal since they apply to individual usage sites, but they appear across all PHP contexts (web, cli, queue-worker).
Closest to 'minor surprise' (t3), +1. The misconception states developers think anonymous classes are 'just shorthand for small named classes,' missing their value in tests and inline interface implementations. Common mistakes include not knowing they can extend classes and implement interfaces, and using them where closures would suffice. These are notable but not severe traps — a competent developer will likely guess some behaviors wrong (especially around capabilities like implementing interfaces) but will learn quickly. The debugging surprise with class_name returning internal identifiers adds another gotcha.
Also Known As
TL;DR
Explanation
Anonymous classes (PHP 7.0+) are declared with new class { ... } and can extend, implement interfaces, and accept constructor arguments. They are ideal for lightweight one-off implementations (mocking an interface inline in a test, creating a small callback object) without the overhead of a named class file. The class has an internal generated name but cannot be referenced by name later. Anonymous classes are slightly slower to instantiate than named classes due to class registration overhead — avoid them in tight loops.
Common Misconception
Why It Matters
Common Mistakes
- Creating named classes for single-use implementations — anonymous classes are cleaner for short-lived objects.
- Assuming anonymous classes cannot implement interfaces or extend — they can do both.
- Using anonymous classes where a simple closure would suffice — closures are lighter for pure function behaviour.
- Debugging anonymous classes is harder — class_name returns an internal identifier; document them clearly.
Avoid When
- The class is instantiated in more than one place — give it a name so it can be reused and referenced in type hints.
- The class carries significant logic — anonymous classes are hard to find, document, and test in isolation.
- You need to type-hint the concrete class anywhere; anonymous classes produce an unspeakable internal name.
When To Use
- Creating lightweight test doubles inline — no need for a dedicated class file for a one-method stub.
- Implementing a simple interface for a single call site where naming the class adds no clarity.
- Factory methods that return a private implementation without exposing the class name to callers.
Code Examples
// Creating a full file just for a trivial one-use implementation$logger = new class implements LoggerInterface {
public function log(string $msg): void { /* no-op */ }
};