Object-Design on Brian Faust

A Composition Root Makes Choices Visible

Thu, 01 Sep 2022 00:00:00 +0000

Remove the ProductPrices binding from a Laravel service provider, then ask the container for QuoteProduct. Laravel refuses to construct it:

Target [App\Application\ProductPrices] is not instantiable while building
[App\Application\QuoteProduct].

Move the same lookup into QuoteProduct::execute() and construction succeeds. The missing dependency does not become visible until a quote request reaches that line. The application object looks simpler because its constructor says nothing. Its object graph is not simpler; part of the graph has moved into method code and configuration.

A Constructor Should Leave a Usable Object

Wed, 01 Dec 2021 00:00:00 +0000

This Subscription exists before it can safely answer a question:

$subscription = new Subscription();
$subscription->id = $ids->next();
$subscription->customerId = $customerId;
$subscription->plan = $plans->get($planCode);
$subscription->status = 'trial';
$subscription->startsAt = $clock->now();
$subscription->trialEndsAt = $subscription->startsAt->modify('+14 days');

Between the first and last line, another method can observe an object without a plan, status, or start time. Forget the last assignment and an active subscription can carry a trial end. Reorder the calls and identity may be consumed for a plan which does not exist.

Adding a factory does not automatically repair this. Neither does replacing new Subscription() with Subscription::create(). The useful question is which boundary owns each decision.

Strategy Chooses How; Command Records What to Do

Sun, 01 Aug 2021 00:00:00 +0000

Two PHP types can have almost identical shapes and still solve different problems:

interface ShippingRate
{
 public function quote(Shipment $shipment): Money;
}

interface ApplicationCommand
{
 public function execute(): void;
}

Both hide behavior behind a method. Both can be injected and tested. Their surface similarity makes “algorithm versus action” an easy first distinction, but it is not enough for application architecture.

The more useful distinction appears after execution fails. A strategy is a collaborator used while another operation is already in progress. A command represents work that can acquire its own lifecycle. Once work must be queued, retried, deduplicated, authorized, or audited independently, it is no longer merely a choice of implementation.

Composition Over Inheritance Is a Decision, Not a Rule

Thu, 01 Jul 2021 00:00:00 +0000

“Favor composition over inheritance” is useful advice right up to the point where it becomes a reflex. Replacing every parent class with an interface and a service-container binding does not make a design better. It merely exchanges one form of coupling for another.

The decision is about how behavior is allowed to vary.

Inheritance fixes variation into a type hierarchy. Composition puts variation behind collaborators that can change independently. When tax, discounts, shipping, and payment rules evolve along different axes, forcing them into one family tree is expensive. When a subtype genuinely preserves a small, stable parent contract, inheritance may be the clearest tool available.