 |
VOOZH | about |
|
VOOZH | about |
This document explains how the Hypervel Container resolves dependencies when requesting services. It covers the resolution methods (make() and get()), the multi-stage resolution pipeline, alias resolution, callback hooks, and how instances are created and cached.
For information about registering services in the container, see Service Binding. For method invocation with dependency injection, see Method Invocation & Dependency Injection. For lifecycle callbacks registration, see Lifecycle Callbacks.
The container provides two primary methods for resolving dependencies: make() and get().
The make() method builds an entry from the container by its name, resolving it fresh each time it is called. This makes the container behave like a factory for the requested service.
make(string $name, array $parameters = []): mixed
Parameters:
$name - The entry name or class name to resolve$parameters - Optional parameters to inject, overriding automatic resolutionThe method performs the following operations:
Sources: src/Container.php109-132
The get() method finds an entry of the container by its identifier and returns it. For singleton bindings, this returns the cached instance if it has been resolved previously. For factory bindings, it creates a new instance.
get(string $id): mixed
Parameters:
$id - The identifier of the entry to look forThe method resolves aliases and delegates to the parent Hyperf container, which handles caching logic for singleton bindings.
Sources: src/Container.php139-146
| Aspect | make() | get() |
|---|---|---|
| Purpose | Factory-style resolution | Standard PSR-11 resolution |
| Parameters | Supports custom parameters | No parameters |
| Caching | Bypasses cache, always creates new | Respects singleton cache |
| Callbacks | Fires full callback pipeline | Fires callbacks on first resolution only |
| Extenders | Applied on every call | Applied on first resolution only |
Sources: src/Container.php109-146
The container implements a sophisticated multi-stage resolution pipeline that provides hooks for cross-cutting concerns.
Sources: src/Container.php109-132 src/Container.php522-578
Before any resolution occurs, the container checks if the requested name is an alias and resolves it to the concrete binding name.
Sources: src/Container.php111-113
The container fires "before resolving" callbacks, allowing hooks to register additional bindings or modify the resolution context before instantiation occurs.
Sources: src/Container.php118 src/Container.php522-531
The actual instance creation is delegated to the parent Hyperf container, which handles:
Sources: src/Container.php120
After the instance is created, any registered extenders are applied in sequence. Extenders are closures that can wrap, modify, or replace the resolved instance.
Sources: src/Container.php125-127
The container fires both "resolving" and "after resolving" callbacks, providing hooks for logging, event broadcasting, or other post-resolution operations.
Sources: src/Container.php129 src/Container.php552-578
The container supports aliasing, allowing multiple names to resolve to the same concrete binding. Alias resolution is recursive, following the alias chain until reaching the concrete binding.
The getAlias() method recursively follows the alias chain:
public function getAlias(string $abstract): string
{
return isset($this->aliases[$abstract])
? $this->getAlias($this->aliases[$abstract])
: $abstract;
}
All resolution methods (make(), get(), set(), unbind()) perform alias resolution before processing, ensuring consistent behavior regardless of which name is used to request the service.
Sources: src/Container.php622-627 src/Container.php111-113 src/Container.php141-143
The container inherits autowiring capabilities from the Hyperf DI container. When resolving a class that hasn't been explicitly bound, the container automatically:
This process is handled by the parent HyperfContainer::make() method that Hypervel delegates to during the resolution pipeline.
Example Resolution Chain:
class DatabaseConnection {
public function __construct(ConfigRepository $config) { }
}
class UserRepository {
public function __construct(DatabaseConnection $db) { }
}
// When resolving UserRepository:
// 1. Container inspects UserRepository constructor
// 2. Sees DatabaseConnection dependency
// 3. Recursively resolves DatabaseConnection
// 4. Resolves ConfigRepository for DatabaseConnection
// 5. Instantiates everything in reverse order
For classes with primitive parameters or complex resolution requirements, use the $parameters argument of make() or register a binding with a factory closure.
Sources: src/Container.php120
The container provides three distinct callback stages that fire during the resolution process. Callbacks can be registered globally (for all resolutions) or for specific types.
| Method | Purpose | Arguments Received |
|---|---|---|
beforeResolving() | Before instance creation | ($abstract, $parameters, $container) |
resolving() | During instance creation | ($object, $container) |
afterResolving() | After instance creation | ($object, $container) |
These callbacks fire before the container attempts to create an instance. They receive the abstract name and parameters, allowing modification of the resolution context.
Registration:
Sources: src/Container.php467-478 src/Container.php522-531
These callbacks fire after the instance is created and extenders are applied, but before after-resolving callbacks. They receive the resolved object.
Registration:
Sources: src/Container.php485-496 src/Container.php552-562
These callbacks fire as the final stage of resolution, after all other processing is complete. They also receive the resolved object.
Registration:
Sources: src/Container.php503-514 src/Container.php570-578
Sources: src/Container.php109-132
Type-specific callbacks support inheritance matching. A callback registered for a parent class or interface will fire when resolving any subclass or implementation:
The matching logic checks both exact type matches and instanceof relationships.
Sources: src/Container.php586-597
Extenders allow modification of resolved instances after creation but before callbacks fire. They are closures that receive the instance and container, returning a potentially modified instance.
extend(string $abstract, Closure $closure): void
The closure receives two parameters:
$service - The resolved instance$container - The container instanceExample usage:
Multiple extenders can be registered for the same abstract. They are applied sequentially in registration order, with each extender receiving the result of the previous one:
Sources: src/Container.php314-324 src/Container.php632-635
When calling extend() on an already-resolved singleton, the container immediately applies the extender to the cached instance and fires rebound callbacks:
Sources: src/Container.php318-321
The container tracks which services have been resolved and maintains a cache of singleton instances.
The resolved() method determines whether an abstract has been resolved at least once:
resolved(string $abstract): bool
This checks the $resolvedEntries array, which tracks all services that have been instantiated. The method resolves aliases before checking:
Sources: src/Container.php219-226
The parent Hyperf container manages instance caching based on binding configuration:
$resolvedEntries after first resolutionmake() call$resolvedEntriesThe get() method always checks the cache first, while make() bypasses the cache check but still stores singletons after creation.
The container provides methods to manipulate the instance cache:
| Method | Purpose |
|---|---|
forgetInstance(string $abstract) | Remove a specific instance from cache |
forgetInstances() | Clear all cached instances |
flush() | Clear instances, aliases, and bindings |
Sources: src/Container.php656-677
Sources: src/Container.php219-226 src/Container.php656-667
The make() method accepts a $parameters array that overrides automatic dependency resolution for specific parameters. This is useful for runtime values that cannot be autowired:
The parameters are passed to the Hyperf resolution logic, which merges them with autowired dependencies based on parameter names or positions.
Sources: src/Container.php109-132
Summary: Dependency resolution in the Hypervel Container follows a sophisticated pipeline that combines alias resolution, callback hooks, Hyperf's autowiring, extenders, and instance caching. The make() and get() methods provide different resolution strategies, while the callback system enables cross-cutting concerns without tight coupling. The container's state management tracks resolved instances and supports cache manipulation for testing and dynamic reconfiguration.
Refresh this wiki