Generator Command Architecture

This document explains the architecture of generator commands in the Hypervel/Devtool package, focusing on the base class pattern, method override system, and orchestration capabilities. For information about how these commands are registered with the framework, see Command Registration System. For details about specific generator implementations, see their respective sections (Model System Generators, HTTP Layer Generators, etc.).

Overview

All generator commands in this package extend the GeneratorCommand base class provided by the Hyperf framework. This base class implements a template method pattern that defines the skeleton of the code generation algorithm, while allowing subclasses to customize specific steps through method overrides. Some generator commands additionally implement an orchestration pattern, programmatically invoking other generators to create related files.

---

Base Class Hierarchy

The following diagram shows the inheritance structure and key methods provided by the base class:

Diagram: Generator Command Class Hierarchy

Sources: src/Generator/ModelCommand.php14-199 src/Generator/FactoryCommand.php11-91 src/Generator/CacheTableCommand.php15-106 src/Generator/ConsoleCommand.php11-52 src/Generator/RuleCommand.php9-32

---

Template Method Pattern

The GeneratorCommand base class implements a template method pattern where execute() defines the overall file generation algorithm. Subclasses customize behavior by overriding specific hook methods:

Diagram: Template Method Execution Flow

Methods highlighted in gray are the primary override points where subclasses inject custom behavior.

Sources: Hyperf framework base class (referenced by all generator commands)

---

Method Override Points

The following table documents the key methods subclasses override to customize generation behavior:

Method	Purpose	Override Frequency	Example Customization
getStub()	Return path to stub template file	Always	Point to custom stub: __DIR__ . '/stubs/model.stub'
getDefaultNamespace()	Define default namespace for generated class	Always	Return 'App\Models' for models, 'App\Rules' for rules
replaceClass()	Replace placeholders in stub with actual values	Often	Add %MODEL%, %COMMAND% replacements
qualifyClass()	Convert short name to fully-qualified class name	Sometimes	Override to skip namespace qualification
getPath()	Determine output file path	Sometimes	Custom paths like database/factories/{$name}.php
alreadyExists()	Check if target file already exists	Rarely	Custom existence checks for migrations
execute()	Complete generation workflow	Rarely	Orchestration, special migration logic

Sources: src/Generator/ModelCommand.php71-88 src/Generator/FactoryCommand.php25-76 src/Generator/ConsoleCommand.php28-44 src/Generator/RuleCommand.php23-31

---

Stub Template and Placeholder Replacement

Each generator command specifies a stub template file through getStub(). The base class reads this template and replaces placeholders with actual values:

Diagram: Stub Processing Pipeline

Example: ConsoleCommand Placeholder Replacement

The ConsoleCommand overrides replaceClass() to add a %COMMAND% placeholder:

src/Generator/ConsoleCommand.php28-34

The stub template uses this placeholder:

src/Generator/stubs/console.stub14

Example: FactoryCommand Custom Placeholders

The FactoryCommand replaces multiple custom placeholders related to the model:

src/Generator/FactoryCommand.php40-58

Sources: src/Generator/ConsoleCommand.php28-34 src/Generator/stubs/console.stub1-28 src/Generator/FactoryCommand.php40-58 src/Generator/stubs/rule.stub1-22

---

Configuration-Based Customization

Generator commands retrieve configuration through getConfig(), allowing users to override default behavior:

Configuration Key	Purpose	Used By
stub	Custom stub template path	All generators
namespace	Override default namespace	Component generators
path	Custom output directory	Factory, migration generators
uses	Base class to extend	ModelCommand
model_namespace	Model namespace for relationships	FactoryCommand

Example: Model Configuration

src/Generator/ModelCommand.php75-87

This allows users to configure custom base classes and namespaces without modifying generator code.

Sources: src/Generator/ModelCommand.php75-87 src/Generator/FactoryCommand.php25-35 src/Generator/ConsoleCommand.php36-44

---

Command Orchestration Pattern

The ModelCommand implements an orchestration pattern where it invokes other generator commands based on command-line options. This creates a coordinated workflow for generating related files:

Diagram: ModelCommand Orchestration Flow

Implementation: Option Processing

The --all flag activates all related generators:

src/Generator/ModelCommand.php35-42

Implementation: Call Method

The call() method programmatically invokes other commands through the console application:

src/Generator/ModelCommand.php192-198

Example: Factory Creation

src/Generator/ModelCommand.php110-118

This orchestration pattern allows developers to generate a complete model scaffold with a single command, while maintaining modularity by delegating to specialized generator commands.

Sources: src/Generator/ModelCommand.php31-65 src/Generator/ModelCommand.php110-190 src/Generator/ModelCommand.php192-198

---

Migration Generator Pattern

Migration generators follow a distinct pattern from component generators. They override execute() completely to implement custom logic for timestamped migration files:

Diagram: Migration Generator Execution Pattern

Example: CacheTableCommand Implementation

The complete execute() override:

src/Generator/CacheTableCommand.php29-59

The custom migration builder:

src/Generator/CacheTableCommand.php61-64

The stub template uses a %TABLE% placeholder:

src/Generator/stubs/cache-table.stub15

Configuration-based table name resolution:

src/Generator/CacheTableCommand.php100-105

This pattern is used by all table migration generators (CacheTableCommand, CacheLocksTableCommand, SessionTableCommand, etc.).

Sources: src/Generator/CacheTableCommand.php29-105 src/Generator/stubs/cache-table.stub1-29 src/Generator/stubs/cache-locks-table.stub1-29

---

Path Resolution Strategies

Different generator types use different strategies for determining output file paths:

Generator Type	Path Strategy	Example
Component Generators	Namespace-based in app/	app/Models/User.php
Factories	Fixed directory with custom path	database/factories/UserFactory.php
Migration Generators	Fixed directory with timestamp	database/migrations/2024_01_01_000000_create_cache_table.php

Example: Component Generator Path Resolution

Component generators use the base class getPath() which combines namespace with base path:

BASE_PATH + namespace path + class name + .php

Example: Factory Custom Path

src/Generator/FactoryCommand.php71-76

Example: Migration Timestamped Path

src/Generator/CacheTableCommand.php34-36

Sources: src/Generator/FactoryCommand.php71-76 src/Generator/CacheTableCommand.php34-36

---

Common Implementation Patterns

Minimal Override Pattern

Simple generators like RuleCommand only override the essential methods:

src/Generator/RuleCommand.php9-32

This minimal approach is sufficient when no custom placeholder replacement or path logic is needed.

Custom Placeholder Pattern

Generators that need domain-specific placeholders override replaceClass():

src/Generator/ConsoleCommand.php28-34

Custom Path Pattern

Generators requiring non-standard output locations override getPath():

src/Generator/FactoryCommand.php71-76

Complete Execution Override Pattern

Complex generators like CacheTableCommand override execute() entirely:

src/Generator/CacheTableCommand.php29-59

Sources: src/Generator/RuleCommand.php9-32 src/Generator/ConsoleCommand.php28-34 src/Generator/FactoryCommand.php71-76 src/Generator/CacheTableCommand.php29-59

---

Summary

The generator command architecture provides a flexible, extensible framework for code generation:

• Inheritance: All generators extend GeneratorCommand from Hyperf
• Template Method Pattern: Base class defines algorithm skeleton, subclasses customize via overrides
• Key Override Points: getStub(), getDefaultNamespace(), replaceClass(), getPath()
• Configuration-Based: Users can customize without modifying generator code
• Orchestration: ModelCommand demonstrates how to coordinate multiple generators
• Migration Pattern: Table generators follow distinct pattern with complete execute() override

This architecture promotes code reuse while allowing precise customization for different generator types.