Table Module Pattern
debt(d7/e7/b7/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no' and the code_pattern is a large Eloquent model with 50+ methods or mixed business/persistence logic. Tools listed (phpstan, deptrac) can flag structural issues but won't directly identify a Table Module misuse or its degeneration into a God Class — that requires careful code review to spot the pattern applied wrongly or growing unbounded.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes a structural pattern choice, not a single-line patch. When a Table Module has grown into a God Class or mixed persistence with presentation, correcting it means redistributing methods across domain objects or introducing a proper Domain Model — a cross-cutting refactor touching many callers and potentially multiple files across the codebase.
Closest to 'strong gravitational pull' (b7). The pattern applies to web and cli contexts broadly and is architectural in nature (tags: patterns, database, architecture). A Table Module, once adopted, shapes how all business logic for a table is organized. When it decays into a God Class, every future feature addition is shaped by the existing accumulation of methods, making it a persistent productivity tax with strong gravitational pull on every subsequent change.
Closest to 'notable trap' (t5). The misconception field explicitly states that developers confuse Table Module with Repository — a documented and common gotcha. Additionally, common_mistakes list growing into a God Class and creating one per every table regardless of need, both well-documented pitfalls. This is a known, learnable trap rather than a catastrophic or systematically contradictory one.
Also Known As
TL;DR
Explanation
Table Module (Martin Fowler, PoEAA): all business logic for a table's rows in one class, operating on collections not individual objects. Good for: moderate business logic that outgrows Transaction Script but does not justify full Domain Model.
Common Misconception
Why It Matters
Common Mistakes
- Growing into a God Class
- Mixing data access with presentation
- One per every table regardless of need
Code Examples
// Logic scattered across files:
// file1.php: $pdo->query('SELECT * FROM orders WHERE...');
// file2.php: $pdo->query('UPDATE orders SET...');class OrderTable {
public function findPendingOverdue(): array { return $this->db->query(...)->fetchAll(); }
public function markAsProcessing(int $id): void { $this->validateTransition($id); $this->db->execute(...); }
}