DEV Community: Christian Nastasi

Value Objects in PHP 8: Let's introduce a functional approach

Christian Nastasi — Sun, 23 Nov 2025 20:42:37 +0000

NOTE: If you're new to Value Objects, I recommend starting with the first article to understand the fundamentals.

Introduction
The Problem with Traditional Validation
Building Blocks
- PHP 8.5 Pipes
- The Validation Context (A Functor)
- A Library of Reusable Validators
- Error Accumulation
- Union Types Instead of Either (Monad)
Conclusion

Introduction

In my previous articles, I've explored Value Objects from basic implementation to advanced patterns, entities, and building custom type systems. Each article built upon the previous, showing how PHP 8's features enable more elegant solutions.

But now, with PHP 8.5, we have a new and powerful ally that truly changes the game: the pipe operator (|>).

This operator opens up new possibilities for functional programming in PHP. It lets us express validation logic in a way that's fundamentally different from what we could do before.

Different and better. But still, I want to keep some consistency in the way the value object should be used.

I'm not a huge fan of functional programming, and I don't want to write all my code in a functional style because I think it can become very cryptic and difficult to maintain. But sometimes, being functional can solve problems in a very elegant way that would be impossible in an OOP approach.

I know PHP programmers aren't usually familiar with functional jargon like functors and monads, so I’ll try not to go too deep into theoretical details and instead keep things at a high level, focusing on a pragmatic approach. Occasionally, though, for the sake of completeness, I’ll mention some of these terms.

I'll break down the approach step by step, showing each building block that enables this validation paradigm.

If you want to play around with this without implementing it yourself, here is a GitHub repository.

The Problem with Traditional Validation

In my previous articles, I explained how Value Objects encapsulate validation rules directly in the constructor. For example:

readonly final class Age
{
    public function __construct(public int $value)
    {
        ($value < 0) or throw new InvalidArgumentException("Age cannot be negative");
        ($value > 150) or throw new InvalidArgumentException("Age cannot exceed 150");
    }
}

While this approach gets the job done, it does have several drawbacks:

Only the first error is reported. As soon as one validation fails, an exception is thrown and further checks are skipped. If there are multiple issues, the user will only see the first one.
Imperative, step-by-step style. The validation logic is written as a series of imperative instructions, describing exactly how PHP should validate.
Validation logic is tightly coupled to each Value Object. Every Value Object contains its own validation code, which makes it difficult to share or reuse validations across different Value Objects.
Composability is lacking. Because the checks are isolated inside each class, it is hard to combine or chain validation rules in a clean or elegant way.
Non-linear code flow. Relying on exceptions for flow control leads to a non-linear and sometimes rather complex structure that can be challenging to maintain.

These issues become even more pronounced when dealing with entities made up of several properties. You are faced with some unappealing choices: validate each property individually and throw an exception at the first problem (which makes for a poor user experience), collect errors by hand (which quickly becomes tedious and error-prone), or bring in a heavy validation library as a dependency.

What if instead we could move validation logic into a library of reusable, composable validators? And what if we could accumulate all the validation errors, rather than stopping as soon as the first one occurs? And what if we can use them inside the Value Object (and not as an external check) so we keep the premise of "when the object is instantiated, the value is formally valid"?

Thanks to PHP 8.5, all of this is now possible. I'll show you how, step by step.

Our goal is to end up with something like the following:

readonly final class Age
{
    // Private constructor
    private function __construct(public int $value) {}

    public static function create(mixed $value): Age|ErrorsBag
    {
        $context = IntegerValue::from($value)
            |> IntegerValue::min(0, "Age cannot be negative")
            |> IntegerValue::max(150, "Age cannot exceed 150");

        return $context->isValid()
            ? new Age($context->getValue())
            : $context->getErrors();
    }
}

Even though the example is straightforward, there are a few important details to notice:

private function __construct(public int $value) {}

The constructor is made private to ensure that all instantiation goes through the create factory method.

$context = IntegerValue::from($value)

The input value is wrapped inside another object, which we will look at in more depth later.

|> IntegerValue::min(0, "Age cannot be negative")
|> IntegerValue::max(150, "Age cannot exceed 150");

Instead of rewriting the validation logic every time, we use a dedicated validation library. Each check can have a custom error message.

return $context->isValid()
    ? new Age($context->getValue())
    : $context->getErrors();

The flow continues all the way to the end, where we check if the value is valid or not. Even at this point, we do not throw exceptions. Instead, we return either the Value Object instance or the errors themselves.

Building Blocks

What I've shown so far is just the final usage. To better understand the example, we need to break it down into different "building blocks" to see what's behind it.

PHP 8.5 Pipes

PHP 8.5 introduces the pipe operator (|>), which allows you to pass the result of one expression as the first argument to the next:

$result = $value
    |> function1(...)
    |> function2(...)
    |> function3(...);

The pipe operator enables a functional programming style that was previously awkward in PHP. It lets us chain operations in a way that's both readable and composable. The ... operator tells PHP that the function requires the result of the previous function as its argument. The only limitation is that the function can have only one argument.

For validation, this is transformative because it lets us express validation as a pipeline:

$value
    |> isString()
    |> minLength(10)
    |> maxLength(200)
    |> startsWith('foo')

Each step in the pipeline transforms the value (or context) and passes it to the next step. This is the foundation of our functional validation approach.

The Validation Context (A Functor)

Instead of throwing exceptions immediately, we need a way to accumulate errors as validation progresses. This is where ValidationContext comes in. From a functional programming perspective, this is actually a functor.

In functional programming, a functor is a type that can be mapped over. It wraps a value and allows transformations while preserving its structure. For validation, we create a functor that holds both the value being validated and any errors that have been collected.

As PHP developers, we're not used to thinking in terms of "functors," so I'll use the term "context" which is perhaps more understandable. A context object that maintains information and accumulates any errors throughout the validation process.

readonly abstract class ValidationContext
{
    private function __construct(
        private mixed $value,
        private array $errors
    ) {}

    protected static function of(mixed $value): self
    {
        return new self($value, []);
    }

    public function validate(callable $predicate, string $errorMessage): self
    {
        $isValid = $predicate($this->value);

        if (!$isValid) {
            return $this->addError($errorMessage);
        }

        return $this; // Continue with the same context
    }

    public function getErrors(): ErrorsBag
    {
        // Convert error messages to ErrorsBag
    }

    public function isValid(): bool
    {
        return empty($this->errors);
    }
}

The context flows through the pipe, accumulating errors as it goes. If validation fails, we add an error but continue processing. This allows us to collect all validation errors, not just the first one.

The context is immutable: each validation step returns a new instance, making it safe to pass through pipes. This immutability is what makes it a functor: we can transform it (add errors, change the value) while maintaining its structure (it's always a ValidationContext).

A Library of Reusable Validators

Instead of writing validation logic inside each Value Object, we create a library of reusable validators.

Consider the traditional approach:

// VALIDATION FOR AGE
($value < 0) or throw new InvalidArgumentException("Age cannot be negative");
($value > 150) or throw new InvalidArgumentException("Age cannot exceed 150");

// VALIDATION FOR PRICE
($value < 0) or throw new InvalidArgumentException("Price cannot be negative");
($value > 100000) or throw new InvalidArgumentException("Price cannot exceed 1000.00€");

Notice the duplication? Both check for minimum and maximum, but the logic is embedded in each class.

Here's how both Age and Price look using the functional approach with a validator library:

// VALIDATION FOR AGE
$context = IntegerValue::from($value)
    |> IntegerValue::min(0, "Age cannot be negative")
    |> IntegerValue::max(150, "Age cannot exceed 150");

// VALIDATION FOR PRICE
$context = IntegerValue::from($value)
    |> IntegerValue::min(0, "Price cannot be negative")
    |> IntegerValue::max(100000, "Price cannot exceed 1000.00€");

For such simple examples, it might not seem worth it. But when we consider more complex validation logic (email, password, specific formats), this approach allows us to avoid reinventing the wheel every time and, more importantly, to have much more readable code, as it makes explicit what validation is being performed.

Compare this to the traditional approach:

No embedded validation logic - validation is delegated to reusable validators
Declarative style - we describe what we validate, not how
Composable - validators are chained together elegantly
Error accumulation - all validation errors are collected, not just the first
Reusable validators - IntegerValue::min() and IntegerValue::max() are used by both Age and Price (and any other Value Object that needs them)
Custom error messages - we can set custom messages for every different value object, giving more context

But what does a validator like this look like? Here is my suggestion:

readonly class IntegerValue extends ValidationContext
{
    public static function from(mixed $value): IntegerValue
    {
        return $value
                |> IntegerValue::of(...)
                |> IntegerValue::isInteger();
    }

    public static function isInteger(?string $errorMessage = null): \Closure
    {
        return static function (ValidationContext $context) use ($errorMessage) {
            $message = $errorMessage ?? "Value must be an integer";

            $newContext = $context->validate(
                fn(mixed $value) => is_int($value),
                $message
            );

            return ($newContext->isValid())
                ? IntegerValue::of(intval($context->getValue()))
                : $context;
        };
    }

    public static function min(int $min, ?string $errorMessage = null): \Closure
    {
        $message = $errorMessage ?? "Value must be at least {$min}";

        return static fn(ValidationContext $context) => $context->validate(
            fn(int $value) => $value >= $min,
            $message
        );
    }

    public static function max(int $max, ?string $errorMessage = null): \Closure
    {
        $message = $errorMessage ?? "Value must be at most {$max}";

        return static fn(ValidationContext $context) => $context->validate(
            fn(int $value) => $value <= $max,
            $message
        );
    }

    public static function between(int $min, int $max, ?string $errorMessage = null): \Closure
    {
        $message = $errorMessage ?? "Value must be between {$min} and {$max}";

        return static fn(ValidationContext $context) => $context->validate(
            fn($value) => $value >= $min && $value <= $max,
            $message
        );
    }
}

The validator methods work in two ways:

from() is a factory method that takes a raw value and creates a ValidationContext, starting the validation pipeline
Methods like min(), max(), isInteger(), and between() are static methods that return closures. These closures take a context and return a context, making them perfect for use in pipe chains

This pattern makes the validators completely reusable across any Value Object that needs integer validation. You compose them in a pipe, and each step transforms the context as it flows through.

The same principle applies to strings:

readonly class StringValue extends ValidationContext
{
    public static function from(mixed $value): StringValue {}
    public static function isString(?string $errorMessage = null): \Closure { }
    public static function minLength(int $min, ?string $errorMessage = null): \Closure { }
    public static function maxLength(int $max, ?string $errorMessage = null): \Closure { }
    public static function email(?string $errorMessage = null): \Closure { }
    public static function hasUppercase(?string $errorMessage = null): \Closure { }
    // ... and many more
}

Instead of embedding validation logic in each Value Object, we compose validators from a shared library. This means:

DRY principle: Write validation logic once, use it everywhere
Consistency: Same validators produce the same behavior
Testability: Test validators independently
Maintainability: Update validation logic in one place

Error Accumulation

Traditional validation stops at the first error. But with the functor approach, we can accumulate all errors. Password validation is a perfect example because a weak password can fail multiple rules at once:

// Traditional approach - stops at first error
try {
    $password = new Password("weak"); // Throws immediately on first failure
} catch (InvalidArgumentException $e) {
    // Only see: "Password must be at least 8 characters long"
    // Never know it also lacks uppercase, numbers, special characters, etc.
}

// New approach - collects all errors
$context = "weak"
    |> StringValue::from(...)
    |> StringValue::minLength(8, "Password must be at least 8 characters long")                  // Fail  
    |> StringValue::maxLength(20, "Password cannot exceed 20 characters")            
    |> StringValue::hasUppercase("Password must contain at least one uppercase letter")          // Fail
    |> StringValue::hasLowercase("Password must contain at least one lowercase letter")   
    |> StringValue::hasNumber("Password must contain at least one number")                       // Fail
    |> StringValue::hasSpecialCharacter("Password must contain at least one special character"); // Fail

if ($context->hasErrors()) {
    foreach ($context->getErrors()->getErrors() as $error) {
        echo $error->message . "\n";
    }
    // Shows all four errors:
    // - Password must be at least 8 characters long
    // - Password must contain at least one uppercase letter
    // - Password must contain at least one number
    // - Password must contain at least one special character
}

This is particularly useful for user-facing validation where you want to show all issues at once, rather than making users fix one error at a time. With password validation, users can see all the requirements they need to meet in a single feedback cycle.

The context persists throughout the pipeline, collecting errors at each step. Only at the end do we check for errors.

Union Types Instead of Either (Monad)

In functional programming, the Either monad is commonly used to represent a value that can be one of two types (typically success or failure). It's a powerful abstraction that helps when working with pipelines and other functional patterns.

In PHP, it is possible to implement the Either monad, but unfortunately, neither the IDE nor the language itself provides native support for it.

Starting from PHP 8.0, we have a similar but different feature: union types. This feature has several limitations compared to the power that the Either monad provides. But for the use case we are exploring, I think union types provide a more expressive and native alternative.

Here are some real examples to illustrate the difference:

The Either Monad Approach

With the Either monad, you would typically wrap results in a monadic container that supports functional composition:

// Usage with Either monad
public static function create(mixed $value): Either
{
    $context = $value
        |> IntegerValue::from(...)
        |> IntegerValue::min(0, "Age cannot be negative")
        |> IntegerValue::max(150, "Age cannot exceed 150");

    return $context->isValid()
        ? Either::right(new Age($context->getValue()))
        : Either::left($context->getErrors());
}

Using it requires method calls, loses type information, and also loses readability:

$result = Age::create(25);

// Functional composition example (but still loses types)
$result = Age::create(25)
    ->map(fn($age) => $age->value * 2)            // Transform if valid
    ->flatMap(fn($value) => Age::create($value)); // Chain another validation


// Imperative example
if ($result->isRight()) {
    $age = $result->getRight();                // IDE doesn't know this is Age
    echo $age->value;                          // No type safety, no autocomplete
} elseif ($result->isLeft()) {
    $errors = $result->getLeft();              // IDE doesn't know this is ErrorsBag
    foreach ($errors->getErrors() as $error) { // No type hints
        echo $error->message;
    }
}

We could improve the Either monad approach using static analysis tools like Psalm or PHPStan with docblock generics, but it still lacks readability and requires knowledge of the functional paradigm. I want to hide as much complexity as possible and keep the usage of Value Objects clean and familiar to regular PHP programmers.

The Union Type Approach

Instead of wrapping results in an Either monad, we can use union types directly:

public static function create(mixed $value): Age|ErrorsBag
{
    $context = $value
        |> IntegerValue::from(...)
        |> IntegerValue::min(0, "Age cannot be negative")
        |> IntegerValue::max(150, "Age cannot exceed 150");

    return $context->isValid()
        ? new Age($context->getValue())
        : $context->getErrors();
}

The return type Age|ErrorsBag is more expressive than the Either monad because:

Native language support: No need for wrapper classes or monadic operations
Direct type checking: Use instanceof directly, no need for isLeft() or isRight() methods
Clearer intent: The types themselves tell you what you're working with
Better IDE support: Autocomplete and type hints work out of the box

Using it is straightforward:

$result = Age::create(25);

if ($result instanceof Age) {
    // Handle valid age - IDE knows $result is Age here
    echo $result->value; // Full autocomplete support
} elseif ($result instanceof ErrorsBag) {
    // Handle validation errors - IDE knows $result is ErrorsBag here
    foreach ($result->getErrors() as $error) {
        echo $error->message;
    }
}

This is type-safe and explicit. The type system ensures you can't accidentally ignore errors or use an invalid value. The IDE provides full autocomplete and type checking at each branch.

Conclusion

Now that we've analyzed each building block one by one, the initial example takes on a whole new meaning:

readonly final class Age
{
    // Private constructor
    private function __construct(public int $value) {}

    public static function create(mixed $value): Age|ErrorsBag
    {
        $context = $value
            |> IntegerValue::from(...)
            |> IntegerValue::min(0, "Age cannot be negative")
            |> IntegerValue::max(150, "Age cannot exceed 150");

        return $context->isValid()
            ? new self($context->getValue())
            : $context->getErrors();
    }
}

Notice what's not in this class:

No if statements
No exception throwing
No embedded validation logic

Instead, we:

Use pipes to chain operations
Use reusable validators from a library
Use context (functor) to accumulate errors
Return a union type for type safety

The validation is declarative: we're describing what we want to validate, not how. The pipe operator makes the flow obvious: start with a value, validate it's an integer, check minimum, check maximum.

Using it is equally elegant:

// Valid age - returns Age object
$age = Age::create(25);

if ($age instanceof Age) {
    echo "Age: {$age->value}"; // 25
}

// Invalid age - returns ErrorsBag with all errors
$result = Age::create(-5);

if ($result instanceof ErrorsBag) {
    foreach ($result->getErrors() as $error) {
        echo $error->message . "\n";
    }
    // Output: "Age cannot be negative"
}

This represents a shift from exception-based validation. Instead of "fail fast," we "collect all failures."

So far, we've only covered Value Objects. The next step in this discussion will be entities: how to handle multiple Value Objects together. But we'll see that in the next article.

File 02: Automation Bias

Christian Nastasi — Thu, 20 Nov 2025 09:38:31 +0000

When Trust Becomes Blind Faith (Introduction)

Your CI/CD pipeline has been green for weeks. The automated tests pass, the linter is happy, deployment scripts run smoothly. Life is good. Until one day, production breaks, and you realize the automation you trusted completely missed a critical bug.

That's Automation Bias: the dangerous tendency to trust automated systems more than they deserve, even when they're wrong.

In psychology, automation bias describes our tendency to favor suggestions from automated decision-making systems and ignore contradictory information made without automation. It's not about laziness, it's about how our brains handle authority, even when that authority is a piece of software.

This bias becomes most dangerous precisely when systems work well. The more reliable a system appears, the more we trust it blindly. We stop questioning, we stop verifying, we stop thinking.

The Silent Failure (The problem)

In software development, automation bias shows up in every corner of our workflow.

A team's automated testing pipeline has been running successfully for months. When a critical bug slips through to production, the team initially assumes the automated tests must be correct and looks for other causes, wasting hours before realizing the tests had a false positive.
A security team receives hundreds of automated alerts daily. After months of mostly false positives, they begin to ignore alerts or dismiss them without investigation. When a real security breach occurs, the automated system correctly flags it, but the team dismisses it as another false positive.
Developers rely heavily on automated code analysis tools to catch bugs and style issues. They become complacent, assuming the tools will catch everything. When the tools miss a subtle logic error that causes a production outage, the team realizes they've stopped doing thorough manual code reviews.
A developer uses an AI coding assistant to generate code. The AI produces syntactically correct code that looks good, so the developer accepts it without thorough review. They trust the AI's output, assuming it understands the full context and edge cases. The code works in most scenarios but fails silently in an edge case, causing a data integrity issue in production.

The bias warps our judgment. We attribute more credibility to systems than to our own expertise. We reduce cognitive load by trusting automation, but in doing so, we become lazy thinkers.

When this happens:

Critical bugs slip through automated checks.
Security threats get ignored due to alert fatigue.
Human expertise degrades from lack of use.
Teams lose the ability to question automated outputs.

Ironically, the better our automation works, the worse we become at noticing when it doesn't.

Keeping Humans in the Loop (Mitigation)

Escaping automation bias begins with remembering that automation should enhance, not replace, human judgment. You can't eliminate automation, but you can design processes that keep you engaged.

Some practical ways:

Always verify critical automated decisions manually. Don't let automation make you passive in monitoring systems.
Question automated outputs regularly. Ask "What could the system be missing?" Make it a habit, not an exception.
Cross-check with multiple sources. Use different tools or methods to validate results. Don't rely on a single automated system for mission-critical decisions.
Maintain manual skills alongside automated tools. Ensure team members stay trained on manual processes even when automation is available.
Design human-in-the-loop processes. Require human confirmation for critical decisions. Make automated decision-making processes explainable.
Implement intelligent alerting that reduces noise. Manage alert fatigue before it makes you ignore real threats.

The goal is not to eliminate automation—that would be counterproductive. The goal is to keep humans engaged, skilled, and questioning. Automation should be a tool, not a crutch. Systems should enhance judgment, not replace it.

Debugging the human mind, one bias at a time.

Value Object in PHP 8: Build your own type system

Christian Nastasi — Wed, 19 Nov 2025 10:57:27 +0000

Table of content

Introduction
The Practical Example
Analysis
Build your own type system
- Integers
- String Values
- The big picture

Introduction

In our previous articles, we learned:

It's time to mix all these concepts together and apply them in a practical example.

This will allow us to create a custom-type system tailored to our application, extending and improving the native one.

The Practical Example

Let's consider a simple yet meaningful example: a library management system. We need to design the data structures to effectively represent that domain. There's no single way to do so; it depends on the specific problem we need to solve.

Analysis

Before writing any code, we should understand what we need to build. There is no greater waste than building the wrong thing or, worse, something useless. This preliminary phase sets the stage for a successful implementation.

An old but gold tool that proved itself useful despite passing years is certainly the UML Class Diagram.

This classic tool helps map out the relationships and hierarchies between different entities within your system. By visually representing how various elements interact, you gain a clear perspective on the structure of your data.

The Book entity

Let's start with the entities. It is easy to assume that the main entity is a book, written by one or more authors.

ISBN

In the real world, a book is identified by an ISBN, which stands for "International Standard Book Number." For the sake of simplicity, we will use a simplified version that doesn't follow the actual rules but is meaningful for the exercise.

Title

A book's title should be at least 2 characters long (the shortest title I can think of is IT, by Stephen King) and shorter than 255 characters (an arbitrary but good enough limit).

Description

A book might have a description, but it is not mandatory. As we did for the title, we set an upper bound size limit to prevent problems with very long strings.

Publish Year

PublishYear is an interesting one. Of course, it should be represented by an integer, but it has several limitations given by the domain itself. I believe it is reasonable to think that a book cannot have been published before the advent of printing, thus not before the first printed book: the Gutenberg bible, printed in 1455. It is equally reasonable to think that the publication date cannot be in the future, so it must be less than or equal to the current year.

Authors

The property authors is a collection of Author, which is an entity itself.
An Author possesses an ID, which could be an integer value or, better, a UUID / ULID.

I personally prefer using a self-generated identifier over a progressive one. When we use autoincremented integers, we have to check which ID was last inserted each time, hoping that no one else requests the same ID and causes a collision. This creates a strong dependency on the persistence layer, which is better to avoid.

Author ID

AuthorId also has a new static method that generates a new, valid Author ID.

Name

Things are a little more complex for the name property: instead of a simple Value Object, we've got a Composite Value Object.

Build your own type system

So far, everything is going well. The data structures appear to accurately depict our domain, and our data remains consistent due to strict validation of our entities and value objects.

However, as many of you have likely noticed, the value objects we defined have numerous similarities, leading to code duplication when recurring patterns emerge.

So, how can we improve? In short, we can develop our base type system, encapsulate the language primitives, and then build our Value Objects and Entities using them.

Looking at the data structures described in the example, we can easily recognize 3 different kinds of value objects:

Integers
- Publish Year
Strings
- ISBN
- Book title
- Book description
- First, last and middle name
Identifiers
- Author ID

Same primitive types but different validation rules. So, how to design them to manage those different rules? The answer is "abstraction".

But let's see how to build those kinds of value objects in practice with real code.

Integers

Let's start writing a Value Object for integer values, which is one of the simplest primitive value objects.

To ensure immutability, we'll add the readonly attribute to the class.

readonly class Integer {
}

Please memorize the following text:

We shouldn't define it as abstract because sometimes we just need a generic integer and nothing more, so we don't have to extend the Integer class for every integer property.

For the constructor, we'll use the final keyword to ensure that no one can change the behavior. Then, we put the validation outside the constructor, with a protected visibility. This allows us to override the "validate" method in case we have special cases to handle that go outside the norm. The value will be public, and there will be no need for getters (because the property is inherited readonly).

public final function __construct(public int $value)
{
    $this->validate();
}

protected function validate():void
{
    /* ... */
}

Let's explore the validate method. For validation, we only need to check if the value is within a certain range. This range should be parametric because it may vary between data. For example, for an Age ValueObject, the range could be between 0 and 140.

To do so, we will use two constants, MIN and MAX.

protected const int MIN = PHP_INT_MIN;

protected const int MAX = PHP_INT_MAX;

We could set both of them as null, but I don't like to deal with nulls when it's not necessary.

Then, inside the validate method, the check is simple.

protected function validate(): void
{
    ($this->value >= static::MIN) or throw InvalidInteger::greaterOrEqualThan(static::MIN, $this->value);
    ($this->value <= static::MAX) or throw InvalidInteger::lessOrEqualThan(static::MAX, $this->value);
}

Remember: always use the static keyword when accessing the constants. If we used the self keyword, the trick doesn't work. If you want to understand why, take a look at the late static binding documentation.

To completeness, let's add also the __toString and the equals methods.

public function __toString(): string
{
    return (string)$this->value;
}

public function equals(Integer $integer): bool
{
    return $integer->value === $this->value;
}

And done. We have all the building blocks that we need.

Now, what if we need to extend and put some limits on our integers? Let's take, for example, the a value object for positive integers (that means value always >= 0).

readonly class PositiveInteger extends Integer
{
    protected const int MIN = 0;
}

That's it. If you have a static range, you just redefine the MIN and MAX constants and nothing more.

But what if we have a dynamic range? If you remember, we have the "PublishYear" Value Object, which has an upper limit based on the current year. If we try to do something like this, the interpreter will raise an error.

// Expression is not allowed as class constant value
protected const int MAX = Carbon::now()->year;

To solve this, we have to override the validate method.

readonly class PublishYear extends Integer
{
    protected const int MIN = 1455;

    protected function validate(): void
    {
        // Don't forget to call the parent method
        parent::validate();

        $currentYear = Carbon::now()->year;

        ($this->value <= $currentYear) or throw InvalidInteger::lessOrEqualThan($currentYear, $this->value);
    }
}

Let's refactor the PublishYear class using this design.

String Values

We need a little more complexity to represent string values. Most string validation is based on length, but sometimes, this is not enough. Take the simplified ISBN we used before as an example: it has a specific format and a specific length. A practical way to check that kind of value is using a regex pattern.

Unfortunately, we cannot call a class String in PHP, so we must find alternatives. The best solutions I've found in those years are StringValue or Text.

Similar to what we did for the Integers, we will have 2 protected (and optional) fields for the minimum and maximum length validation. If not specified, the check will not be performed.

We will also have a regex field, which is also optional.

Then, we can build a hierarchy that specialises in the kind of string values that we need.

But is it really necessary to create a Value Object for every field, then? The answer is no; it depends. Specialize the generic value objects only if the children's class needs something more; for example, adding methods/fields or equality must be strict (based on class and not only on the value); otherwise, you can use the generic one.

The big picture

Following this approach, and with a domain bigger than the one we are using as an example, it's easy to wrap all primitives, and what comes out is something similar to this.

Time to code

Now that we have an exact picture in mind, we can start to code.

There are a lot of people who think analysis is useless and is not worth the time spent on it. After 2 decades of developing stuff, I can affirm without uncertainty that there's no more important thing than analysis, and there's not much time lost as the time spent coding the wrong thing or worse, a feature that will never be used.
We developers like thinking a lot about all the possibilities and what-ifs, but please stop doing that. YAGNI is the way (You Aint Gonna Need It).

Integers

Implementing an Integer Value Object is pretty straightforward. The 2 constants MIN and MAX give the necessary freedom to restrict the range and keep simplicity in the extension.

readonly class Integer
{
    public const MIN = PHP_INT_MIN;
    public const MAX = PHP_INT_MAX;

    final protected function __construct(public int $value)
    {
        $this->validate();
    }

    protected function validate(): void
    {
        ($this->value >= static::MIN) or throw InvalidInteger::moreOrEqualsThan(static::MIN, $this->value);
        ($this->value <= static::MAX) or throw InvalidInteger::lessOrEqualsThan(static::MAX, $this->value);
    }

    public static function create(int $value): static
    {
        return new static($value);
    }

    public function equals(Integer $integer): bool
    {
        return $this->value === $integer->value;
    }

    public function __toString(): string
    {
        return (string)$this->value;
    }
}

For example, if we want to extend it and have, for example, a PositiveInteger Value Object, we need to do this:

readonly class PositiveInteger extends Integer
{
    public const MIN = 1;
}

Conclusion:

Reinforcing the value of a custom type system using Value Objects
Encouraging developers to explore and experiment with domain-specific types in PHP 8
Emphasizing how this approach contributes to a more expressive and reliable codebase

File 01: The Curse of Knoledge

Christian Nastasi — Wed, 19 Nov 2025 10:01:51 +0000

The Invisible Wall Between Minds (Introduction)

Imagine trying to explain how to ride a bicycle to someone who's never touched one. You might say: "Just balance and pedal!", forgetting that balance is something your body learned through dozens of falls.

That's the Curse of Knowledge: once you know something, it becomes incredibly hard to imagine not knowing it.

In psychology, this cognitive bias describes the difficulty experts have in communicating with novices because they can't easily recall what it was like to be a beginner. Knowledge reshapes perception, rewriting our internal model of the world. What once was complex now feels obvious, and we unconsciously assume it's obvious to everyone else, too.

This bias doesn't require arrogance; it simply exploits how our brain compresses experience. Once we've mastered a concept, we stop noticing the steps we took to get there.

When Seniority Becomes a Blindfold (The problem)

In software development, the Curse of Knowledge shows up everywhere.

A senior developer writes a "simple" regex that nobody else understands.
A tech lead drafts documentation that skips crucial setup steps.
A mentor reviews a junior's code and asks, "Why didn't you just use dependency injection?" assuming that the junior knows what is being talked about.

The bias warps our empathy. We assume that everyone around us shares our mental models, our vocabulary, and our intuition about architecture.

But knowledge is not contagious by proximity: it must be transferred, not assumed.

When this happens:

Onboarding slows down.
Documentation becomes cryptic.
Communication turns from collaborative to hierarchical.
Juniors feel inadequate, seniors feel misunderstood.

Ironically, the more we know, the worse we can become at teaching or explaining it.

Remembering the Path You've Forgotten (Mitigation)

Escaping the curse begins with awareness. You can't "un-know" something, but you can simulate ignorance, reconstruct what it felt like not to know.

Some practical ways:

Explain as if to your past self. When teaching or documenting, imagine you're talking to you from two years ago.
Focus on clarity, not just correctness. Ask others, "Was this clear?" instead of "Is this right?"
Encourage reverse mentorship. Juniors can point out where explanations fail; treat those as signals, not annoyances. Also, ask them to repeat what they had understood.
Replace jargon with analogies. The human mind learns through stories more than syntax.
Write as a teacher, not just a technician. Every pull request, comment, and commit message can be an act of mentorship.

The goal is not to simplify the world, it's to make it navigable for others. Knowledge should be a bridge, not a barrier.

Debugging the human mind, one bias at a time.

File 00: Introduction to Cognitive Biases

Christian Nastasi — Wed, 19 Nov 2025 09:43:49 +0000

Welcome to "The Cognitive Bias Files", a newsletter exploring the fascinating intersection between psychology and technology.

Have you ever wondered why, despite your best intentions, you don’t always make the right decisions? Have you ever read a text multiple times without noticing errors, only for someone else to spot them instantly? Have you ever been driving and then, after a few minutes, realized you're heading in the wrong direction, as if you were on autopilot?

It feels like our minds are... bugged, right? Spoiler: It's not just a feeling, they really are!

We live in a really complicated world, and I don’t mean just nowadays. Our brains have to handle a lot of different signals from our senses, like what we see, hear, touch, taste, and feel in terms of balance, temperature, pain, hunger, fullness (and much more).

In order to deal with this complexity, our brains take shortcuts: interpolations, heuristics, and mental optimizations to process the endless flow of information around us. It’s a bit like how a JPEG encoder compresses images: efficient, but there is a loss of information. It filters everything that could be filtered in order to keep only the necessary information.

But sometimes, what is discarded is too much, and problems then arise. Especially in today's modern world, where the amount of information is much greater than in the past. This is especially true if you work as a software developer, where you have to communicate in an unambiguous way to a computer (that is, write software) and manage complex systems.

And I’ll be honest: this newsletter is partly an excuse. I’m not a psychologist or researcher, I'm just a tech enthusiast who became curious. I wanted to explore why intelligent people (including myself) often make irrational decisions in code, projects, and life in general. I started this project as a way to motivate myself, and I’m excited to share that journey with you. So please cheer for me.

Why This Newsletter Exists?

After years in tech, I realized something important: we spend huge amounts of time learning new languages, frameworks, and tools, but almost no time learning how we ourselves think. We optimize our code, but not our brains.

In this newsletter, instead, we will do just that, one bias at a time.

Each post will explore a cognitive bias that affects how we design, build, and work together in the tech world. We’ll mix light theory with practical, real-life examples.

We’ll explore the biases that most often mess with our daily work, such as:

The Curse of Knowledge: when expertise makes you bad at explaining
Anchoring and Confirmation Bias: when your first idea becomes your only idea
The Planning Fallacy: when “it’ll take two days” becomes two weeks
Automation Bias: when you trust the system a bit too much

And much more. This isn’t about blaming or judging. We all fall into these traps, that’s what makes us human. The goal is to understand how our brain works, so we can make better, more deliberate decisions.

Your Feedback Matters

Have you spotted these biases in your own projects? Do you have stories or examples worth sharing? Leave a comment or send me a message. I’d love to hear real cases from the field and your experiences in general. The comment section will be a nice place where continue the discussion about biases.

Conclusion

Technology evolves faster than ever, but human psychology hasn’t had a firmware update in centuries. By learning to recognize our cognitive “bugs,” we can become better developers, teammates, and leaders.

The goal isn’t to eliminate biases: that’s impossible. The goal is to see them, name them, and work with them.

So, welcome aboard. Let’s start debugging our brains, one bias at a time.

🤝 Written by a human (me) with some AI assistance. Don’t worry, the biases are still 100% human.

Value Objects in PHP 8: Entities

Christian Nastasi — Thu, 21 Dec 2023 08:36:59 +0000

Introduction
Entities
- Identity in Entities
- Mutability and State Changes
- Persistence Beyond a Single Transaction
Immutable Entities
Entity Version
Mixing Entities with Value Objects
Practical Considerations: Choosing Between Value Objects and Entities
Conclusion

Introduction

In the previous articles, we learned how to create fundamental value objects and recognized their role in enhancing the stability and reliability of our applications.

This article will delve into another architectural pattern closely connected to value objects: Entities.

First, let's refresh our memory on the essential qualities of a Value Object.

Value Objects are the unsung heroes of our code, bringing immutability and predictability to our applications. They encapsulate small data pieces, ensuring their state remains constant once set. This predictability simplifies our code and contributes to overall system stability.

A Value Object describes a value, a measurement or something unitary and atomic. This is why if two Value Objects have the same value, they can be considered the same object (also if they are two different instantiated objects).

Explaining the concept in simple terms: 50 € equals 50 €.
However, 2 apples are different from 2 pears.

Entities

Despite Entities shares a structural similarity with Value Objects, they possess distinct characteristics and qualities.

For example, an Entity possesses a unique identity, allowing it to undergo state changes while retaining its individuality. This distinct identity makes it suitable for scenarios where persistence and mutability are crucial.

Let's dive deeper into the qualities that define an entity in our PHP applications.

Identity in Entities

The initial characteristic defining an entity is its unique identity. Unlike Value Objects, Entities bear a distinctive mark that distinguishes them. This identity maintains consistency throughout their existence, providing a stable reference point.

An entity's identity can take various forms, typically manifesting as a number or a string (examples include UUID, email, fiscal code). This concept aligns closely with the idea of a primary key in databases.

Take the example of a "User" entity in a system. The unique identifier (ID) linked to each user plays a crucial role in defining their identity. This significance endures, facilitating differentiation even when other attributes, such as the username or email, undergo alterations.

class User
{
    public function __construct(
        private readonly int $id,
        private string $name,
        private string $email
    ) {
        $this->validateId();
        $this->validateName();
        $this->validateEmail();
    }

    public function getId():int 
    {
        return $this->id;
    }

    public function getName():string 
    {
        return $this->name;
    }

    public function getEmail():string 
    {
        return $this->email;
    }

    public function __toString():string
    {
        return "{$this->id} | {$this->name} | {$this->email}";
    }

    // Validators
    // Additional methods for operations involving user data
}

// Usage:
$user = new User(1, 'John Doe', 'john@example.com');

// Output: 1 | John Doe | john@example.com
echo $user;

This example shows a structural difference between an Entity and a Value Object. Unlike Value Objects, Entities can't use public readonly properties because attributes like name and email might change. Uncontrolled changes are undesirable, so these properties are private/protected. Access to them is managed through getter and setter methods.

A __toString method can also help debug your entity easily.

Later in the article, we'll explore how to craft an entity with both immutable and mutable aspects, leveraging public readonly properties instead of traditional getters and setters.

Mutability and State Changes

Unlike Value Objects, Entities can undergo state changes during their lifecycle. This mutability grants them the flexibility to adapt to various scenarios, mirroring the dynamic nature of the real entities they represent.

In the context of our "User" entity example, users can dynamically update their profile information, alter their preferences, or modify their roles within a system. The inherent capacity of Entities to evolve over time makes them well-suited for modelling elements that experience variations in their attributes.

class User
{
    public function __construct(
        private readonly int $id,
        private string $name,
        private string $email
    ) {
        $this->validateId();
        $this->validateName();
        $this->validateEmail();
    }

    // Getters
    // validators
    // __toString

    public function changeName(string $name): void
    {
        $this->name = $name;

        $this->validateName();
    }

    public function changeEmail(string $email): void 
    {
        $this->email = $email;

        $this->validateEmail();
    }
}

// Usage:
$user = new User(1, 'John Doe', 'john@example.com');

// Output: 1 | John Doe | john@example.com
echo $user; 

$user->changeName('Frank Doe');

// Output: 1 | Frank Doe | john@example.com
echo $user; 

$user->changeEmail('frank@example.com');

// Output: 1 | Frank Doe | frank@example.com
echo $user;

The presented example shows the dynamic nature of the "User" entity. The entity's state is modified through the changeName and changeEmail methods, allowing users to update their information seamlessly and safely (using validators).
This mutability is a crucial aspect of Entities, enabling them to reflect the evolving characteristics of the real-world entities they represent.

It's noteworthy that two Entities, even if their attribute values differ, can be recognized as the same entity when sharing a common identifier. This suggests the possibility of referencing the same entity, albeit potentially representing different versions.

This lays the groundwork for exploring the concept of an "entity version," a topic we'll delve into in a subsequent chapter.

Persistence Beyond a Single Transaction

Entities exhibit persistence beyond a single transaction or request, ensuring their endurance through various interactions with the system. This persistence proves invaluable when modelling elements requiring consistent storage, retrieval, and referencing.

Consider an "Order" entity within an e-commerce system. Following a purchase, the order retains its identity, and all associated details, such as purchased items and the customer, persist within the system's database. This enduring presence allows for future reference and retrieval, maintaining a comprehensive record of transactions.

Similarly, once registered, a "User" will be persisted and retrieved each time access to the system occurs.

When storing Entities, a recommended pattern is the Repository Pattern. I will delve into it more extensively in the future, but for now, suffice it to know that it abstracts the concept of an "entity collection".

In an entity collection, you can add, update or delete an entity or retrieve it using the identifier. In an evolved collection, you can also search by some criteria.

So, we first define a contract with methods like add, update, delete and findById for managing and retrieving Entities.

interface UserRepository 
{
    public function add(User $user):void;

    public function update(User $user):void;

    public function delete(User $user):void;

    public function findById(int $id):?User;

    public function findByEmail(string $email):?User;
}

Then, let the interface concrete implementation take care of the persistence and be responsible for the consistency of the data. This means that the concrete implementation has to ensure that everything will be done in a single transaction: if more than one write is necessary and an error occurs, then a rollback must be done. No broken data should be left behind.

Also, the code that will use the contract is unaware of where and how the entity will be stored, which could be anywhere (in a database, a file, or a remote service).

This pattern will also improve your testing suite a lot. Switching your concrete implementation with an in-memory repository will dramatically reduce the time needed to run a functional test suite.

Immutable Entities

As we hinted at in the preceding chapters, one viable approach enabled by the use of public readonly properties is immutability, as we've already seen in the two previous articles of this series.

This implies that a new instance is generated with every modification to the Entity. Here's how the "User" entity might appear using this approach.

class User
{
    public function __construct(
        public readonly int $id,
        public readonly string $name,
        public readonly string $email
    ) {
        $this->validateId();
        $this->validateName();
        $this->validateEmail();
    }

    // Validators
    // __toString

    public function changeName(string $name): User
    {
        return new User($this->id, $name, $this->email);
    }

    public function changeEmail(string $email): User 
    {
        return new User($this->id, $this->name, $email);
    }
}

// Usage:
$user = new User(1, 'John Doe', 'john@example.com');

// Output: 1 | John Doe | john@example.com
echo $user; 

$newUser = $user->changeName('Frank Doe')
                ->changeEmail('frank@example.com');

// Output: 1 | Frank Doe | frank@example.com
echo $newUser; 

// Output: 1 | John Doe | john@example.com
echo $user;

The first noticeable change is that now the properties are no longer private but public and readonly. This implies that getter methods are no longer necessary, and information access could be performed directly using the properties.

The second change is that the changeName and changeEmail methods now return a new "User" instance, allowing us to use a fluent syntax and chain multiple modifications in succession.

The last observation is that the data remains unchanged in the initial "User" instance. Consequently, we end up with two instances of the same entity (as they share the same identifier) but with different data. This could lead to errors if not handled carefully. A potential solution to this issue will be addressed shortly in the "Entity Version" chapter.

However, the drawback of this approach lies in the fact that, especially in highly structured and large Entities, creating a new object instance might not be efficient, especially if done frequently. Still, it could be an interesting approach to ensure the robustness of your application.

Entity Version

As we've seen in the previous chapters, when comparing Entities, the only parameter available is their identifier. Determining if two instances of the same entity possess identical data becomes challenging when internal data changes.

One might initially consider using a counter that increments upon internal data modification. The implementation could look something like this:

class User
{
    public function __construct(
        public readonly int $id,
        public readonly string $name,
        public readonly string $email,
        public readonly int $version = 0
    ) {
        $this->validateId();
        $this->validateName();
        $this->validateEmail();
    }

    // Validators
    // __toString

    public function changeName(string $name): User
    {
        return new User($this->id, $name, $this->email, $this->version + 1);
    }

    public function changeEmail(string $email): User 
    {
        return new User($this->id, $this->name, $email,  $this->version + 1);
    }
}

However, this solution presents several issues and cannot be effectively used to ascertain the strict equality of two Entities:

$user = new User(1, 'John Doe', 'john@example.com');

$newUser1 = $user->changeName('Frank Doe');
$newUser2 = $user->changeEmail('frank@example.com');

// Output: 1 | John Doe | john@example.com | v0
echo $user;  

// Output: 1 | Frank Doe | john@example.com | v1
echo $newUser1; 

// Output: 1 | John Doe | frank@example.com | v1
echo $newUser2;

// Output: bool(true)
var_dump($newUser1->version === $newUser2->version);

We need to find another solution. An intriguing approach is to create a non-random hash string based on entity data, providing a stable and comparable version identifier. A simple way to achieve this is as follows:

class User
{
    public readonly string $version;

    public function __construct(
        public readonly int $id,
        public readonly string $name,
        public readonly string $email,
    ) {
        $this->validateId();
        $this->validateName();
        $this->validateEmail();

        $this->version = $this->calculateVersion();
    }

    // Validators
    // __toString
    // setter

    private function calculateVersion(): string 
    {
         return md5((string)$this);
    }
}

$user = new User(1, 'John Doe', 'john@example.com');

$newUser1 = $user->changeName('Frank Doe');
$newUser2 = $user->changeEmail('frank@example.com');
$newUser3 = $newUser1->changeName('John Doe');

var_dump($user->version === $newUser1->version);     // false
var_dump($user->version === $newUser2->version);     // false
var_dump($newUser1->version === $newUser2->version); // false
var_dump($user->version === $newUser3->version);     // true

Of course, many different hash functions could be used for this purpose, but I just wanted to demonstrate the concept, so I used the simplest one. With this trick, by the way, some optimization could be done. For example, store an entity only if changed or decide if a cache is invalid and needs a refresh, using the hash as a reference.

Mixing Entities with Value Objects

In all my examples, I have consistently used primitive properties for simplicity. However, nothing forbids us from applying what we've learned in the previous articles and incorporating Value Objects within our Entities.

Here's an example of the "User" entity transformed using Value Objects:

class User
{
    public readonly string $version;

    public function __construct(
        public readonly UserId $id,
        public readonly UserName $name,
        public readonly Email $email,
    ) {
        $this->version = $this->calculateVersion();
    }

    public function changeName(UserName $name): User
    {
        return new User($this->id, $name, $this->email);
    }

    public function changeEmail(Email $email): User 
    {
        return new User($this->id, $this->name, $email);
    }

    public function __toString(): string
    {
        return "{$this->id} | {$this->name} | {$this->email}";
    }

    private function calculateVersion(): string 
    {
         return md5((string)$this);
    }
}

Property validation essentially disappears in this adaptation. The rest of the class remains quite similar to the version with primitives. However, it carries the advantage of centralizing validation rules for certain properties repeated across multiple Entities.
Of course, like the Composite Value Objects, we might need to validate business rules between correlated properties.

Practical Considerations: Choosing Between Value Objects and Entities

Understanding when to use Value Objects versus Entities is pivotal for effective system design. Here are some practical considerations:

Use Value Objects When:

The concept you're modelling doesn't require a unique identity.
Immutability and predictability are paramount.
You're dealing with smaller, isolated pieces of data.

Use Entities When:

A unique identity is crucial for the concept.
The element undergoes state changes during its lifecycle.
Persistence and adaptability are significant requirements.

Conclusion

In conclusion, this article explored the architectural pattern of Entities closely connected to Value Objects in PHP applications. The fundamental qualities of Value Objects, such as immutability and predictability, were revisited to set the stage for understanding Entities.

Entities, distinguished by their unique identity and mutability, were examined in-depth, showcasing how Entities can effectively model real-world entities, allowing for state changes while maintaining a stable identity.
The persistence of Entities beyond a single transaction was discussed, emphasizing their importance in scenarios requiring consistent storage and retrieval.

Implementing Immutable Entities using public readonly properties was presented as an alternative approach. This approach involves creating new instances for each modification, ensuring the integrity of the original data. The concept of an "entity version" was introduced, exploring methods to handle changes in entity data over time.

The article also demonstrated the integration of Value Objects within Entities, showcasing how these patterns can collaborate to enhance code clarity and maintainability. Practical considerations for choosing between Value Objects and Entities were outlined, guiding developers based on specific system requirements.

Ultimately, the choice between Value Objects and Entities depends on the nature of the concepts being modelled and the desired system characteristics.

By mastering these architectural patterns, PHP developers can design robust, predictable, and adaptable applications that align with best practices in software architecture.

Is PHP still a viable choice in 2023?

Christian Nastasi — Thu, 07 Dec 2023 12:12:58 +0000

Hello, community. I hope to spark a thoughtful discussion rather than ignite a war among us. I'd love to hear your perspectives on the following topic.

Over the past decade, I've been immersed in the world of PHP, witnessing its remarkable evolution alongside the growth of its ecosystem. Throughout these years, I've cultivated a robust and maintainable design philosophy rooted in principles like DDD, Clean Architecture, and SOLID. While PHP may not be a flawless language, its continuous improvement has resulted in a positive and smooth programming experience.

PHP boasts an active community, a plethora of libraries, outstanding frameworks, adherence to standards (PSRs), the convenience of Composer, Dependency Injection (DI) containers, and much more.

However, the current trend in the market and among companies leans heavily toward the Node.js, TypeScript, and React/Angular stack. Despite adapting to and working with this stack, I find it doesn't quite match the same ease and fluidity that PHP provides.

Perhaps it's a matter of personal preference or a gap in my knowledge, but the JavaScript stack, especially with TypeScript, presents challenges. While TypeScript offers significant power and expressiveness, it can be easy to inadvertently create a tangled mess in your code. Generics, though potent, are sometimes overused.

Error messages often prove cryptic, leaving me puzzled about what went wrong. Functional programming, while effective in managing application flow, demands strict discipline.

Contrary to the organized principles outlined by Uncle Bob in his Clean Code book, the functional approach seems to encourage a more chaotic coding style with chains, folds, maps, and various other constructs. These constructs, while intending to enhance code readability, often hide behind the original intention of the code. This can lead to an increase in cyclomatic complexity and a departure from the Single Responsibility Principle, which should be applied even in the context of functional programming.

Library stability and standardization, comparable to PHP's PSR, seem lacking in the JavaScript community. While there are libraries for almost everything, custom solutions are frequently necessary. For instance, working with message brokers reveals a notable absence of mature options akin to Symfony Messenger.

My experience has been marked by moments of frustration. It could be attributed to my reluctance to leave the comfort of what I know best.

Nevertheless, I persist in believing that PHP remains a viable and compelling stack even in 2023.

What are your thoughts? I'm eager to hear your perspectives on this ongoing debate.

Value Objects in PHP 8: Advanced usage

Christian Nastasi — Sun, 03 Dec 2023 21:45:55 +0000

Introduction
Different kinds of value objects
Factory methods & private constructors
Alternatives to exceptions
Conclusion

Introduction

In the previous article, we explored the power of Value Objects in improving code quality, system robustness, and minimizing the need for extensive validation. Now, let's dive deeper to enhance our understanding and usage of this crucial tool.

Different kinds of value objects

When dealing with Value Objects, it's beneficial to classify them into different types based on their complexity. In my experience, I've identified three main types:

Simple value objects
Complex value objects
Composite value objects

There could be a fourth, but it would essentially be a mix of these three types.

Simple Value Object

Simple Value Objects encapsulate a single value, often representing a primitive value or basic concept within your domain. These objects are ideal for straightforward attributes or measurements.

Let's take the Age Value Object introduced in the previous article as an example:

readonly final class Age 
{
     public function __construct(public int $value)
     {
          $this->validate();
     }

     public function validate(): void
     {
          ($this->value >= 18) 
              or throw InvalidAge::adultRequired($this->value);

          ($this->value <= 120) 
              or throw InvalidAge::matusalem($this->value);
     }

     public function __toString(): string 
     {
          return (string)$this->value;
     }

     public function equals(Age $age): bool 
     {
         return $age->value === $this->value;
     }
}

In this example, Age is a Simple Value Object that represents a person's age. It encapsulates a single integer value and includes a validation mechanism to ensure the age falls within a reasonable range.
The __toString method allows easy conversion to a string, and the equals method compares two Age objects for equality.

When creating Simple Value Objects, consider the following guidelines:

Single Responsibility:
Keep the Value Object focused on representing a single concept or attribute, often corresponding to a primitive value.
Immutability:
Once created, a Simple Value Object should not be altered. Any changes should result in the creation of a new instance.
Validation:
Include validation logic within the constructor to ensure the object is always in a valid state.
String Representation:
Implement the __toString method for convenient string conversion when needed.
Equality Check:
Provide an equals method to compare two instances for equality.

By adhering to these guidelines, you create Simple Value Objects that enhance the clarity, stability, and reliability of your code.

Complex Value Object

While Simple Value Objects encapsulate a single value, Complex Value Objects handle more intricate structures or multiple attributes, forming a richer representation within your domain. These objects are well-suited for modelling complex concepts or aggregations of data.

Consider the Coordinates Value Object:

readonly final class Coordinates 
{
     public function __construct(
          public float $latitude,
          public float $longitude
     )
     {
          $this->validate();
     }

     private function validate(): void
     {
          ($this->latitude >= -90 && $this->latitude <= 90) 
              or throw InvalidCoordinates::invalidLatitude($this->latitude);

          ($this->longitude >= -180 && $this->longitude <= 180) 
               or throw InvalidCoordinates::invalidLongitude($this->longitude);
     }

     public function __toString(): string 
     {
          return "Latitude: {$this->latitude}, Longitude: {$this->longitude}";
     }

     public function equals(Coordinates $coordinates): bool 
     {
          return $coordinates->latitude === $this->latitude
              && $coordinates->longitude === $this->longitude;
     }
}

In this example, the Coordinates Value Object represents geographic coordinates with latitude and longitude. The constructor ensures the object's validity, validating that latitude falls within the range [-90, 90] and longitude within [-180, 180]. The __toString method provides a readable string representation, and the equals method compares two Coordinates objects for equality.

When creating Complex Value Objects, consider the following guidelines:

Structured Representation:
Model the object to reflect the complexity and structure of the corresponding domain concept.
Validation:
Implement validation logic within the constructor to ensure the object is always in a valid state.
String Representation:
Include a meaningful __toString method for better readability and debugging.
Equality Check:
Provide an equals method to compare two instances for equality.

This approach allows you to create Complex Value Objects that effectively represent intricate concepts within your application, such as geographic coordinates in this case.

Although not obvious in this example, Complex Value Objects often require more detailed checks. It's not just about individual values but also how they relate to each other.

Consider this example:

readonly final class PriceRange
{
    public function __construct(
        public int $priceFrom,
        public int $priceTo
    ) {
        $this->validate();
    }

    private function validate(): void
    {
        ($this->priceTo >= 0) 
            or throw InvalidPriceRange::positivePriceTo($this->priceTo);

        ($this->priceFrom >= 0) 
            or throw InvalidPriceRange::positivePriceFrom($this->priceFrom);

        ($this->priceTo >= $this->priceFrom) 
            or throw InvalidPriceRange::endBeforeStart($this->priceFrom, $this->priceTo);
    }

    // ...(rest of the methods)
}

In this case, even if each price is fine on its own, we need to ensure that the priceTo must come after or is the same as the priceFrom.

Composite Value Object

Composite Value Objects are powerful structures that combine multiple Simple or Complex Value Objects into a cohesive unit, representing more intricate concepts within your domain. This allows you to build rich and meaningful abstractions.

Let's illustrate this with an example using an Address Value Object:

readonly final class Address 
{
    public function __construct(
        public Street $street,
        public City $city,
        public PostalCode $postalCode
    ) {}

    public function __toString(): string 
    {
        return "{$this->street}, {$this->city}, {$this->postalCode}";
    }

    public function equals(Address $address): bool 
    {
        return $address->street->equals($this->street)
            && $address->city->equals($this->city)
            && $address->postalCode->equals($this->postalCode);
    }
}

In this example, the Address Composite Value Object is composed of Street, City, and PostalCode. Each sub-object encapsulates a single value, and together they form a more comprehensive representation of an address.

The __toString method provides a readable string representation, and the equals method compares two Address objects for equality.

When creating Composite Value Objects, consider the following guidelines:

Composition:
Assemble multiple Simple or Complex Value Objects to create a more intricate structure.
Abstraction:
Represent complex concepts within your domain using a composite structure.
String Representation:
Include a meaningful __toString method for better readability and debugging.
Equality Check:
Provide an equals method to compare two instances for equality.

In many cases, validating a Composite Value Object is not necessary as its validity is already ensured by its components. However, just like in Complex Value Objects, there might be scenarios where logic demands validation across different properties of the object. In such cases, validation is, of course, required.

Factory methods & Private constructors

In the examples presented so far, we've explored relatively simple value objects. However, everyday development introduces challenges when value objects have internal representations differing from their externals.

To illustrate this challenge, let's consider the DateTime concept. The date "24th December 2023, 4:09:53 PM, Rome time zone" can be represented in various ways, such as seconds since January 1, 1970, or as an RFC3339 string.

Unlike languages like Java or C#, PHP lacks constructor overloading. Here, the factory method design pattern, employing one or more static methods, becomes invaluable for controlled object instantiation.

Let's take a closer look at this value object:

class DateTimeValueObject
{
    private DateTimeImmutable $dateTime;

    private function __construct(DateTimeImmutable $dateTime)
    {
        $this->dateTime = $dateTime;
    }

    // Factory method to create from timestamp
    public static function createFromTimestamp(int $timestamp): self
    {
        ($timestamp >= 0) or InvalidDateTime::invalidTimestamp($timestamp);

        $dateTime = new DateTimeImmutable();
        $dateTime = $dateTime->setTimestamp($timestamp);

        return new self($dateTime);
    }

    // Factory method to create from RFC3339 string
    public static function createFromRFC3339(string $dateTimeString): self
    {
        $dateTime = DateTimeImmutable::createFromFormat(DateTime::RFC3339, $dateTimeString);

        ($dateTime !== false) or throw new InvalidDateTime::invalidRFC3339String($dateTimeString);

        return new self($dateTime);
    }

     public static function createFromParts(int $year, int $month, int $day, int $hour, int $minute, int $second, string $timezone): self
    {
        (checkdate($month, $day, $year) && self::isValidTime($hour, $minute, $second)) or throw InvalidDateTime::invalidDateParts($year, $month, $day, $hour, $minute, $second, $timezone);

        $dateTime = new DateTimeImmutable();

        $dateTime = $dateTime
            ->setDate($year, $month, $day)
            ->setTime($hour, $minute, $second)
            ->setTimezone(new DateTimeZone($timezone));

        return new self($dateTime);
    }

    private static function isValidTime(int $hour, int $minute, int $second): bool
    {
        return ($hour >= 0 && $hour <= 23) && ($minute >= 0 && $minute <= 59) && ($second >= 0 && $second <= 59);
    }

    public static function now(): self 
    {
        return new self(new DateTimeImmutable());
    }

    public function getDateTime(): DateTimeImmutable
    {
        return $this->dateTime;
    }

    // __toString & equals methods
}

// Usage examples
$dateTime1 = DateTimeValueObject::createFromTimestamp(1703430593);
$dateTime2 = DateTimeValueObject::createFromRFC3339('2023-12-24T16:09:53+01:00');
$dateTime3 = DateTimeValueObject::createFromParts(2023, 12, 24, 16, 9, 53, 'Europe/Rome');
$dateTime4 = DateTimeValueObject::now();

Let's focus on some details:

Constructor Accessibility: In this example, the constructor is marked as private, restricting instantiation to within the class itself. However, it's essential to note that this is a design choice, not a strict requirement. Constructors can also be public, depending on the desired encapsulation and usage patterns. The private constructor here emphasizes controlled instantiation through factory methods, providing a clear interface for creating instances.
Factory Methods with Input Validation: Each factory method includes input validation to ensure the integrity of the provided data before creating the DateTimeValueObject. Whether the constructor is private or public, the factory methods act as gatekeepers, enforcing validation rules.
createfromParts Method: This method showcases the flexibility of creating a DateTimeValueObject by specifying individual parts. The input validation within this method ensures that the constructed object reflects a valid date and time.
now Method: The now method exemplifies a common factory method for creating instances representing the current date and time. It leverages the DateTimeImmutable class internally to capture the current moment.
__toString & equals Methods: While not explicitly demonstrated in this example, implementing __toString for obtaining a string representation and equals for comparing instances are typical practices.

This approach highlights the versatility of using private or public constructors based on design preferences, reinforcing the idea that design patterns accommodate varying needs and choices.

Another interesting use of the factory method is to simplify the instantiation of a composite value object, like the Address Value Object seen before.

readonly final class Address 
{
    private function __construct(
        public Street $street,
        public City $city,
        public PostalCode $postalCode
    ) {}

    public static function create(
        string $street, 
        string $city, 
        string $postalCode
    ): Address 
    {
        return new Address(
            new Street($street),
            new City($city),
            new PostalCode($postalCode)
        );
    }

    // ... (rest of the methods)
}

As mentioned before, the private constructor keeps things tidy by forcing developers to use only the create to obtain a new instance of the Value Object.

Also, with PHP 8, we can use a very cool trick:

$data = [
   'street'     => 'Via del Colosseo, 10',
   'city'       => 'Rome',
   'postalCode' => '12345'
];

$address = Address::create(...$data);

This concise PHP 8 trick utilizes named arguments and array spread operator, showcasing a succinct and expressive method for object instantiation.

Alternatives to exceptions

Some people might have reservations about using exceptions as they interrupt the execution flow and, if not handled, can create issues.

However, there are alternative, more functional approaches that can come to our aid.

Either

For those unfamiliar with the concept of Either, we could succinctly (and poorly) describe it as a type that can be either the right value or not (and the opposite of right is left).

If you wanna know more, take a look here or here.

In a simplified implementation, it might look like this:

/**
 * @template L
 * @template R
 */
final class Either
{
    /**
     * @param bool $isRight
     * @param L|R $value
     */
    private function __construct(private bool $isRight, private mixed $value)
    {
    }

    /**
     * @param L $value
     * @return Either<L, R>
     */
    public static function left(mixed $value): Either
    {
        return new self(false, $value);
    }

    /**
     * @param R $value
     * @return Either<L, R>
     */
    public static function right(mixed $value): Either
    {
        return new self(true, $value);
    }

    /**
     * @return bool
     */
    public function isRight(): bool
    {
        return $this->isRight;
    }

    /**
     * @return L|R
     */
    public function getValue(): mixed
    {
        return $this->value;
    }
}

Now, let's apply Either in our Address Value Object creation:

readonly final class Address 
{
   // ... (rest of the methods)

    /**
     * @returns Either<InvalidValue,Address>
     */
    public static function create(
        string $street, 
        string $city, 
        string $postalCode
    ): Either
    {
        try {
            return Either::right(new Address(
                new Street($street),
                new City($city),
                new PostalCode($postalCode)
            ));
        } catch (InvalidValue $error) {
           return Either::left($error);
        } 
    }

    // __toString & equals methods
}

Handling the result:

$address = Address::create('', '', '');

if ($address->isRight()) {
   // do stuff in case of success
} 
else {
   // do stuff in case of error

   /** @var InvalidValue $error */
   $error = $address->getValue();

   echo "Error: {$error->getMessage()}";
}

This approach provides a flexible way to manage outcomes, allowing distinct handling paths for success and error scenarios.

While several libraries implement Eithers in PHP, the lack of generics requires heavy use of static analysis tools, like PSalm or PHPStan. That's why sometimes might be tricky working with types.

Union types

Alternatively, PHP 8.0 introduced the concept of Union Types. Similar to the Either example, the create method returns two possible values:

readonly final class Address 
{
   // ... (rest of the methods)

    public static function create(
        string $street,
        string $city, 
        string $postalCode
    ): InvalidValue|Address
    {
        try {
            return new Address(
                new Street($street),
                new City($city),
                new PostalCode($postalCode)
            );
        } catch (InvalidValue $error) {
           return $error;
        } 
    }

    // __toString & equals methods
}

Handling the result:

$address = Address::create('', '', '');

if ($address instanceof InvalidValue) {
   // do stuff in case of error

   echo "Error: {$address->getMessage()}";
} 
else {
   // do stuff in case of success
}

When it comes to handling errors in PHP, there is no one-size-fits-all solution. The decision between using Either and Union Types depends on your project's specific needs.

Either provides a granular approach, enabling you to distinctly manage different outcomes. It emphasizes a structured and explicit error-handling strategy.

Union Types, on the other hand, leverage the language's built-in capabilities and simplify the syntax. This approach might be more aligned with the philosophy of "let it fail fast" by handling errors directly where they occur.

In conclusion, choosing the right error-handling approach in PHP involves thoughtful consideration of your project's context and needs. Either and Union Types are valuable tools, providing flexibility to tailor your strategy. The key is selecting an approach that aligns seamlessly with your project's philosophy, promoting clarity, maintainability, and resilience.

Conclusion

In wrapping up our exploration of Value Objects in PHP, we've covered various aspects to enhance your understanding and usage of this important tool.

We started by looking at Simple Value Objects, which represent basic concepts in your code. These objects encapsulate single values and come with guidelines like keeping them focused, making them immutable, ensuring validation, having a string representation, and providing a method for equality checks. By sticking to these principles, we can create clear and reliable code.

Moving on to Complex Value Objects, we tackled structures with more intricacies. These objects handle multiple attributes or complex structures, modeling richer concepts in your domain. The guidelines for complex value objects involve representing the domain concept well, implementing validation, having a meaningful string representation, and providing a method for equality checks.

The journey peaked with Composite Value Objects, where we saw the combination of multiple simple or complex value objects into a unified structure. This allows us to represent even more complex concepts, like addresses in our example. The guidelines here involve assembling different value objects, abstracting complex concepts, ensuring a readable string representation, and providing a method for equality checks.

Next, we explored Factory Methods & Private Constructors. We saw how these can be beneficial when dealing with value objects with internal representations differing from their externals. The DateTimeValueObject served as an example, showcasing the use of factory methods for controlled object instantiation. The flexibility of using private or public constructors was highlighted, emphasizing design choices.

In our final leg, we looked at Alternatives to Exceptions, introducing the Either type and PHP 8.0's Union Types. Both these approaches offer different ways of handling errors. Either provides a structured strategy, and Union Types simplify syntax for a "fail fast" philosophy.

In conclusion, as you navigate PHP development, choosing between Either and Union Types depends on your project's needs. Both are valuable tools, offering flexibility to tailor your error-handling strategy. The key is selecting approaches that align with your project's context, ensuring code clarity, maintainability, and resilience. As you explore these possibilities, may your code be strong, your abstractions meaningful, and your decisions well-informed. Happy coding!

Value Objects in PHP 8: Building a better code

Christian Nastasi — Thu, 30 Nov 2023 04:08:04 +0000

Introduction
Problems with primitives
Class as types
Key Qualities of Value Objects
Wrapping It Up

Introduction

In the world of coding, keeping our code clean and strong is a big deal.

The Value Object pattern has the potential to significantly enhance your code quality, making it more robust and maintainable.

In this article, I will explain how to implement the pattern and how this will add some "sugar" to your code, using the latest features introduced by PHP 8.1 and PHP 8.2.

Problems with primitives

Before we jump into Value Objects, let's talk about the issues with basic data types. Here are three common problems:

1. Invalid values

Simple data types don't have built-in checks to ensure the data is valid. This can lead to unexpected issues in our code.

An age could be represented by an integer, but of course, cannot be negatives or more than 120 (more or less). Maybe in our domain makes sense that age should be more or equal than 18 years old.

An email could be represented by a string, but it's not. It is a subset of all possible strings, and several checks are necessary to ensure is valid.

We possibly have a lot of different places in our code that use those values, but we can trust no one, and we had to ensure that our data is consistent. Consequently, we must validate the data passed as an argument every time.

This leads to a validation logic duplication issue. Each of these duplicated logic could potentially differ from each other, leading to inconsistencies.

function logic1(int $age): void 
{
    ($age >= 18) or throw InvalidAge::adultRequired($age);

    // Do stuff
}

function logic2(int $age): void 
{
    ($age >= 0) or throw InvalidAge::lessThanZero($age);
    ($age <= 120) or throw InvalidAge::matusalem($age);

    // Do stuff
}

Using Value Objects should do the trick. It will simplify a lot your code and also ensure consistency in your data.

readonly final class Age 
{
     public function __construct(public int $value)
     {
          ($value >= 18) or throw InvalidAge::adultRequired($value);
          ($value <= 120) or throw InvalidAge::matusalem($value);
     }
}

function logic1(Age $age): void 
{
    // Do stuff
}

function logic2(Age $age): void 
{
    // Do stuff
}

In this way, you are sure that if an instance of Age exists, it is valid and consistent, everywhere in your code, without checking every time.

2. Mixing Up Arguments

When dealing with functions that take similar types of data, it's easy to mix up the order of arguments. This can cause hard-to-spot bugs.

function logic1(string $name, string $surname): void 
{
    // Logic error, 
    // $name is switched with $surname, unintentionally
    logic2($name, $surname);
}

function logic2(string $surname, string $name): void {
    // Do stuff
}

This type of bug is particularly tricky, and currently, there isn't a built-in check that could help us prevent it.

There are only two ways to solve this issue:

Using Value Objects: The interpreter itself or static analysis tools can easily recognize when there's a type mismatch.

function logic1(Name $name, Surname $surname): void 
{
    // Static analysis error
    // Expected Surname, found Name
    logic2($name, $surname);
}

function logic2(Surname $surname, Name $name): void {
    // Do stuff
}

Using named arguments: Introduced in PHP 8.0. In this way, order doesn't matter.

function logic1(string $name, string $surname): void 
{
    logic2(name: $name, surname: $surname);
}

3. Accidental Changes

Simple data types can be changed without us realizing it. When we pass them to a function, that function might accidentally modify the original data.

function logic1(int &$age): void 
{
    if ($age = 42) { // BUGS alert
        echo "That's the answer\n";
    }

    echo "Your age is $age\n"; // It will print always 42
}

Given that is rare to pass arguments by reference using &, this example has got not one but two bugs:

$age = 42 is an assignment, not a comparison. It overwrites the current value without us noticing it and everything that uses that value after will be affected by this bug.
Changing a value passed by reference means that the variable outside the call will be changed as well. This could be intentional, but sometimes it's not.

Using Value Objects will solve this issue because they grant immutability.

final readonly class Age
{
    public function __construct(public int $value)
    { // validation }
}

function logic1(Age $age): void 
{
    // Interpreter error
    // cannot write a readonly property
    if ($age->value = 42) { 
        echo "That's the answer\n";
    }

    echo "Your age is $age\n"; 
}

Classes as Types

Value Objects fix these problems by treating classes as types. Unlike simple data types, Value Objects wrap their data in a class. This helps us control and validate our data better.

Key Qualities of Value Objects

To make the most of Value Objects, we need to focus on a few important things:

1. Can't Change It (Immutability)

Value Objects should stay the same once we create them. This helps us avoid unexpected changes. In the past, prior to PHP 8.1, that was achieved by having private/protected properties and getters only. Setters were prohibited.

If there is a reason why the inner data has to change, then a new instance will be created, without changing the current instance.

PHP 8.1 simplified a lot introducing readonly properties and property promotion.

class Age // PHP 8.1
{
    public function __construct(public readonly int $value)
    {
        ($value >= 18) or throw InvalidAge::adultRequired($value);
        ($value <= 120) or throw InvalidAge::matusalem($value);
    }
}

Prior to PHP 8.1


class Age // PHP < 8.1
{
   private int $value;

    public function __construct(int $value)
    {
        ($value >= 18) or throw InvalidAge::adultRequired($value);
        ($value <= 120) or throw InvalidAge::matusalem($value);

        $this->value = $value;
    }

    public function value():int { return $this->value; }
}

The following example shows how to deal with changes in the value object.
As you can see, no instance property is changed. Instead, a new instance was created.

final readonly class Money // PHP 8.2
{
    public function __construct(
        public int $amount,
        public string $currency
    ) {
        ($amount > 0) or throw InvalidMoney::cannotBeZeroOrLess($amount);
    }

    public function sum (Money $money): Money 
    {
        if ($money->currency !== $this->currency) {
            throw InvalidMoney::cannotSumPearsWithApples($this->currency, $money->currency);
        }

        $newAmount = $this->amount + $money->amount;

        return new Money($newAmount, $this->currency);
    }
}

2. Easy to Compare (Comparability)

Making Value Objects comparable means we can easily check if they are the same or different. This comes in handy when sorting or searching.

// Money
public function equals(Money $money): bool 
{
    return $this->amount === $money->amount
        && $this->currency === $money->currency;   
}

// code
$thousandYen = new Money(1000, Currency::YEN);
$thousandEuro = new Money(1000, Currency::EURO);

$thousandYen->equals($thousandEuro); // false

Because of course, ¥1000 is not the same as €1000.

3. Always Good Data (Consistency)

A Value Object should always represent something valid. By checking and validating inside the object, we make sure it's always in good shape.

This means that the validation should be done inside the constructor to ensure that if the instance exists, then it's valid. Always!

WARNING!
Be careful with deserializers: sometimes they build the object without calling the constructor.

An interesting approach could be having a validate method, called inside the constructor and after one of this kind of deserializing process.

public function __construct(public string $value)
{
    $this->validate();
}

private function validate(): void 
{
    // Do the validation stuff
}

For example, using Serde PHP deserializer, you must add the attribute #[PostLoad] to make it call after the instantiation.

#[PostLoad]
private function validate(): void 
{
    // Do the validation stuff
}

This is because most of them use this reflection method under the hood

public ReflectionClass::newInstanceWithoutConstructor(): object

4. Easy to debug (Debuggability)

It's a good practice to equip Value Objects with an easy way to debug themself. In the case of a simple value object, a __toString method shall do the job. Otherwise, in the case of a composite value object (with a lot of properties and inner other value objects) a toArray is suggested. Or else, a serializer might be used.

final readonly class Name
{ 
    public function __construct(public string $value) {}

    public function __toString(): string 
    { 
        return $this->value; 
    }
}

final readonly class Surname
{ 
    public function __construct(public string $value) {}

    public function __toString(): string 
    { 
        return $this->value; 
    }
}

final readonly class Person
{ 
    public function __construct(
        public Name $name, 
        public Surname $surname
    ){}

    public function __toString(): string
    {
        return "{$this->name} {$this->surname}";
    }

    public function toArray(): array 
    {
        return [
            'name' => (string)$this->name,
            'surname' => (string)$this->surname
        ];
    }
}

Wrapping It Up

In conclusion, embracing the Value Object pattern in PHP 8.2 significantly enhances code quality, making it more robust and maintainable. By treating classes as types, focusing on immutability and always-valid data, and leveraging features introduced in PHP 8.1 and 8.2, developers can create more stable and resilient applications. Adding Value Objects to your coding toolkit not only improves the look of your code but also simplifies the development process and sets the stage for a more scalable and error-resistant codebase.

DEV Community: Christian Nastasi

Value Objects in PHP 8: Let's introduce a functional approach

Table of Contents

Introduction

The Problem with Traditional Validation

Building Blocks

PHP 8.5 Pipes

The Validation Context (A Functor)

A Library of Reusable Validators

Error Accumulation

Union Types Instead of Either (Monad)

The Either Monad Approach

The Union Type Approach

Conclusion

File 02: Automation Bias

When Trust Becomes Blind Faith (Introduction)

The Silent Failure (The problem)

Keeping Humans in the Loop (Mitigation)

Value Object in PHP 8: Build your own type system

Table of content

Introduction

The Practical Example

Analysis

The Book entity

ISBN

Title

Description

Publish Year

Authors

Author ID

Name

Build your own type system

Integers

String Values

The big picture

Time to code

Integers

Conclusion:

File 01: The Curse of Knoledge

The Invisible Wall Between Minds (Introduction)

When Seniority Becomes a Blindfold (The problem)

Remembering the Path You've Forgotten (Mitigation)

File 00: Introduction to Cognitive Biases

Why This Newsletter Exists?

Your Feedback Matters

Conclusion

Value Objects in PHP 8: Entities

Table of contents

Introduction

Entities

Identity in Entities

Mutability and State Changes

Persistence Beyond a Single Transaction

Immutable Entities

Entity Version

Mixing Entities with Value Objects

Practical Considerations: Choosing Between Value Objects and Entities

Use Value Objects When:

Use Entities When:

Conclusion

Is PHP still a viable choice in 2023?

Value Objects in PHP 8: Advanced usage

Table of contents

Introduction

Different kinds of value objects

Simple Value Object

Complex Value Object

Composite Value Object

Factory methods & Private constructors

Alternatives to exceptions

Either

Union types

Conclusion

Value Objects in PHP 8: Building a better code

Table of contents

Introduction

Problems with primitives

1. Invalid values

2. Mixing Up Arguments

3. Accidental Changes