- What is the DefaultInterface in php-standard-library/default?
- It is a small contract that lets a class expose a standardized default instance through a single getDefault() method returning static. Instead of scattering null checks, empty collections, or ad-hoc factory calls, consuming code can simply ask any implementing class for its canonical default. It belongs to the broader php-standard-library ecosystem and is deliberately a focused, dependency-free interface rather than a full framework feature.
- How do I install php-standard-library/default with Composer?
- Install it with composer require php-standard-library/default. The package is contract-only and dependency-free, so there are no service providers to register, config files to publish, or assets to compile. Once installed, any class can implement DefaultInterface and expose a getDefault() method.
- Which Laravel and PHP versions support DefaultInterface?
- The package declares no strict framework requirement, so Composer will resolve it in most modern Laravel applications. Because the interface uses a static return type, it works best on PHP 8.1 with Laravel 10 or newer, where the typing is fully understood by PHPStan, Psalm, and IDE autocompletion. Older setups can still use it, but you lose some of the static analysis benefits.
- How do I implement DefaultInterface in a Laravel class?
- Add implements DefaultInterface to the class and provide a public function getDefault(): static that returns the default instance. Most implementations return a new static instance built with sensible constructor values, or a cached singleton when the object is immutable. It is plain PHP, so it works cleanly with constructor promotion, readonly properties, and Laravel helpers.
- Can I bind default instances in Laravel's service container?
- Yes. You can register a default directly, for example $this->app->bind('default-user', fn () => User::getDefault()), or bind a class to its default instance so injection always resolves to it. This keeps Laravel's dependency injection in control while your classes define what a sane default looks like. Avoid eager initialization inside a service provider's boot method if getDefault() builds heavy objects.
- How does DefaultInterface improve unit and integration testing in Laravel?
- Tests can call User::getDefault() instead of hand-building fixtures or writing createMock(User::class) for every scenario, which cuts setup boilerplate and keeps expectations consistent. Because every implementing class exposes its default the same way, test setup stays uniform across services, jobs, and API responses. Existing tests that instantiate classes directly may need small updates, but the long-term maintenance cost usually drops.
- Does getDefault() cause performance issues or shared state problems?
- The interface itself adds no overhead; the cost depends entirely on what your implementation builds. If getDefault() opens database connections or loads large object graphs, resolve it lazily through Laravel's container rather than eagerly during boot. If you cache a default as a singleton, make it immutable or request-scoped so state cannot leak between requests.
- Should I use DefaultInterface on Eloquent models and domain objects?
- It fits domain models, value objects, and configuration classes where a predictable default makes sense, such as a guest user, an empty order, or a default response object. It is a poor fit for primitive defaults like returning an empty array, or for highly dynamic defaults that depend on the current user or database state. In those cases keep the logic in Laravel container bindings or configuration instead.
- How is DefaultInterface different from Laravel's App::bind() or default parameter values?
- Laravel's container bindings and default parameter values are configured from the outside and resolved at runtime, while DefaultInterface declares the default on the class itself. The two complement each other: the interface standardizes what a default looks like, and the container decides when and how it is injected. Use bindings when defaults must vary per environment, and the interface when a class has one canonical default.
- Is php-standard-library/default production-ready and what are the alternatives?
- It is a minimal, dependency-free contract with no runtime logic of its own, so the technical risk of adopting it is low. The real risk is adoption discipline, such as adding the interface to every class or hardcoding defaults that should stay configurable through Laravel bindings. Alternatives include plain static factory methods, container bindings, or PSR-style factory interfaces, but none give you the same standardized getDefault() contract across a codebase.