Laravel中app()->make(ClassA)与new ClassA()的区别及特性咨询

Hey there! Let's dive into the differences between app()->make(ClassA::class) and new ClassA() in Laravel, along with what each approach is designed for and their key features.

This is the vanilla PHP way of instantiating a class, and it works exactly as you'd expect outside Laravel too:

• Core Goal: Create a direct instance of the class with full manual control over its dependencies.
• Key Features:
  • You're responsible for passing all constructor arguments: If ClassA requires dependencies like Logger or DatabaseConnection, you have to instantiate and pass those yourself (e.g., new ClassA(new Logger(), new DatabaseConnection())).
  • Bypasses Laravel's Service Container entirely: No container binding rules, singleton checks, or automatic dependency resolution come into play here.
  • Creates a fresh instance every time: Each call to new ClassA() gives you a brand new object—no reuse of existing instances.
  • Ideal for simple, self-contained classes: Think utility classes with no external dependencies, or cases where you want explicit control over every part of the instance.

This approach uses Laravel's Service Container to resolve your class, which is a central part of how Laravel manages dependencies and objects:

• Core Goal: Resolve a class instance using Laravel's dependency injection and object management capabilities, reducing boilerplate and enabling flexible configuration.
• Key Features:
  • Automatic dependency injection: The container will automatically find and inject all required constructor dependencies (as long as those dependencies are also resolvable by the container—either via their own bindings or being concrete classes). You don't need to pass any arguments unless you want to override the container's defaults.
  • Respects container bindings: If you've registered a binding (e.g., binding an PaymentGatewayInterface to a StripeGateway implementation, or marking ClassA as a singleton), make() will follow those rules. For example, a singleton binding will return the same instance every time you call make().
  • Supports runtime overrides: You can pass additional parameters to make() to override specific dependencies (e.g., app()->make(ClassA::class, ['customDependency' => $myCustomInstance])).
  • Enables testability: In unit tests, you can bind a mock or fake version of ClassA into the container, and make() will return that fake instance instead of the real one—no need to modify your production code.
  • Triggers container events: The container fires events when resolving classes, which you can listen to for additional logic (like logging or modifying the instance right after it's created).

• Reach for new ClassA() when:
  • The class has no dependencies (or very simple ones you want to handle manually).
  • You don't need any of the Service Container's features (singletons, binding overrides, etc.).
  • You want explicit control over every aspect of the instance's creation.
• Use app()->make(ClassA::class) when:
  • The class has complex dependencies that you don't want to manually instantiate and pass.
  • You need to leverage container features like singletons, interface bindings, or runtime overrides.
  • You're building code that needs to be testable with mock dependencies.
  • You're working within Laravel's ecosystem (like controllers, middleware, or service providers) where the container is already the standard way to resolve objects.

内容的提问来源于stack exchange，提问作者Deemantha