Manager Pattern

The Manager Pattern provides a driver-based extensibility system for managing multiple implementations of the same service. It enables lazy instantiation, driver caching, custom driver registration, and automatic method forwarding. This pattern is used throughout the support package for services like databases, caches, queues, and Redis connections that require multiple backend implementations.

For information about how managers integrate with facades, see Facade System. For information about how managers are registered with the container, see Service Provider System. For the overall architecture context, see Architecture Overview.

---

Purpose and Design Goals

The Manager pattern addresses the need for services that support multiple backend implementations ("drivers") while maintaining a consistent API. Key design goals include:

Goal	Implementation
Driver Abstraction	Abstract base class manages driver lifecycle
Lazy Loading	Drivers created only when first accessed
Instance Caching	Driver instances reused across calls
Extensibility	Custom drivers registered via closures
Convention-based	Driver creation follows naming convention
Transparent API	Method calls forwarded to default driver

The Manager pattern is essential for any service that needs to support multiple backends (e.g., Redis, Memcached, File cache) without changing application code.

Sources: src/Manager.php13-157

---

Class Architecture

Manager Base Class Structure

Sources: src/Manager.php13-37

Key Properties

Property	Type	Purpose
$container	ContainerInterface	Hyperf DI container for dependency resolution
$config	ConfigInterface	Configuration repository for driver settings
$customCreators	array	Map of driver names to custom creator closures
$drivers	array	Cache of instantiated driver instances

Sources: src/Manager.php14-28

---

Driver Resolution Flow

Resolution Process

Sources: src/Manager.php49-84

Driver Method

The driver() method is the primary entry point for driver resolution:

Resolution Logic:

1. Use provided driver name or fall back to getDefaultDriver()
2. Check if driver already instantiated in $drivers cache
3. If not cached, call createDriver() to instantiate
4. Cache the driver instance for subsequent calls
5. Return the driver

Sources: src/Manager.php49-61

Driver Creation Methods

Driver creation follows a convention-based approach with fallback to custom creators:

Method	Purpose	Example
createDriver(string $driver)	Main creation logic with conventions	Called internally by driver()
create{Driver}Driver()	Convention-based method	createRedisDriver(), createMemcachedDriver()
callCustomCreator(string $driver)	Execute registered custom creator	Used for extended drivers

Convention: For driver name "redis", the manager looks for method createRedisDriver() (using Str::studly() conversion).

Sources: src/Manager.php68-92

---

Custom Driver Registration

Extending with Custom Drivers

Sources: src/Manager.php99-104

Extension API

Parameters:

• $driver: Name of the custom driver
• $callback: Closure that receives ContainerInterface and returns driver instance

Example Usage Pattern:

Sources: src/Manager.php99-104

Custom Creator Execution

The callCustomCreator() method invokes the registered closure:

The closure receives the DI container, enabling full access to application services for driver construction.

Sources: src/Manager.php89-92

---

Manager Subclass Implementation

Concrete Manager Example

Implementation Requirements

To create a concrete manager, subclasses must:

1. Implement getDefaultDriver() - Returns the default driver name
2. Implement driver creation methods - Following naming convention create{Driver}Driver()
3. Access configuration - Use $this->config for driver-specific settings
4. Use container - Leverage $this->container for dependency injection

Sources: src/Manager.php42-43

---

Dynamic Method Forwarding

Magic Method Call

The Manager implements __call() to forward method calls to the default driver:

Sources: src/Manager.php153-156

Implementation

This enables transparent API usage:

Sources: src/Manager.php153-156

---

Integration with Hyperf Framework

Container and Configuration Integration

Sources: src/Manager.php33-37

Constructor Injection

The manager receives the DI container and resolves the configuration interface. This provides:

• Access to container for driver dependency injection
• Configuration reading for driver-specific settings
• Service resolution in custom driver creators

Sources: src/Manager.php33-37

---

Cache Management

Driver Cache Operations

Method	Purpose	Use Case
getDrivers()	Retrieve all cached drivers	Debugging, inspection
forgetDrivers()	Clear entire driver cache	Testing, reconfiguration
setContainer()	Replace container instance	Testing, rebinding

Sources: src/Manager.php109-144

Clearing Driver Cache

This method clears all cached driver instances, forcing re-creation on next access. Useful for:

• Testing scenarios requiring fresh instances
• Runtime configuration changes
• Memory management in long-running processes

Sources: src/Manager.php139-144

---

Usage Patterns in Application Code

Basic Driver Access

Pattern Examples

Default Driver:

Named Driver:

Custom Driver:

Sources: src/Manager.php49-156

---

Manager Pattern in System Architecture

Managers in the Hypervel Stack

Sources: src/Manager.php13-157

---

Key Characteristics Summary

Characteristic	Description
Abstract Base	Managers extend Manager abstract class
Lazy Creation	Drivers instantiated only when accessed
Instance Caching	Drivers cached in $drivers array
Convention-based	Driver methods follow create{Name}Driver() pattern
Extensible	Custom drivers via extend() method
Container-aware	Full access to DI container
Config-aware	Configuration reading via ConfigInterface
Transparent API	Method forwarding via __call() magic method
Stateless	Driver state managed by driver instances

Sources: src/Manager.php13-157