Value Objects

Make your code simpler

Who am IProduct Developer - Systems Architect - Freelancer - Development Manager

Past experienceSenior Developer for CleverbugLecturer at the Digital Skills AcademyDirector of Tercet, software development consultancy

Current positionSoftware Development Manager for OliveMedia

Barry O Sullivan

Design Patterns

When developing systems, there are common patterns of problems that emerge.

Design patterns are common, named solutions to these problems.

The ValueObject pattern is one of these patterns.

It’s simple, easy to integrate and can bring a lot of clarity to your code with minimal investment or technical overhead.

So lets get to it . . .

The Problem

public function change_name($firstname, $lastname){ if (!is_string($firstname) || $firstname == “”) {

throw new InvalidNameException(“Firstname is invalid”); } if (!is_string($lastname) || $lastname == “”) {

throw new InvalidNameException(“Lastname is invalid”); } $this->firstname = $firstname; $this->lastname = $lastname;}

Have you ever written code like this?

GuardingThis is called Guarding.

You are guarding against bad input

The idea is that you can’t trust the data sent by other objects/developers, it might be invalid and break your system, or worse, it might seem to work until it breaks later. Guarding protects you against inconsistent state.

Guarding is as old as software development, it’s even recommended in the Mythical Man Month, which is nearly 40yrs old.

Too much guardingThe problem arises when you start adding this logic everywhere.

You end up with• Duplicated code• Messy Logic• Poor legibility

Which leads to a system that’s very difficult to modify and understand.

This leads to more bugs, not less.

Developers

ExcessiveGuarding

The SolutionHow do we solve this problem?

With encapsulation!

You create a class that represents the value.

On creation, it gets passed the basic types and it checks if they’re valid.• If they are not, an exception is thrown.• If they are, then the object is successfully created.

That’s the basic gist of it. Everywhere you need to ensure data integrity, use one of these and you can guaranteeThat the data is valid.

Example, Name as a ValueObjectclass Name implements ValueObject { private $firstname; private $lastname;

public function __construct($firstname, $lastname) {

if (!is_string($firstname) || $firstname == “”) { throw new InvalidNameException(“Firstname ‘$firstname’ is invalid”);

}if (!is_string($lastname) || $lastname == “”) {

throw new InvalidNameException(“Lastname ‘$lastname is invalid”);}$this->firstname = $firstname;

$this->lastname = $lastname;}

………

Using the Name ValueObject//Controller method to change namepublic function change_name(){ $user = $this->user_repository->fetch($this->user_id); $name = new Name(Input::get(‘firstname’), Input::get(‘lastname’)); $user->change_name($name); $this->user_repository->store($user);}

. . . . . .//Then in our User classpublic function change_name(Name $name){

$this->name = $name;}

ValueObjects represent the valueKey Concept:

A value object represents the value, not the data contained within it.

You shouldn’t care about the internal data when using VOs for business logic.

When you want to reference a value, use a value object.

The only place the internals matter is when you’re encoding/decoding them for transmission (JSON/HTML) or storage (MySQL/REDIS), nowhere else.

ValueObjects in the wild1. They are immutableOnce set, you cannot change their values.In other words, you cannot change their state.If you need to change one, simply create a new one and replace the reference to the old one.

2. They are comparableTwo value objects of the same type can be compared to check their values. This makes business rules easier to build and check.(Works a treat with the specification pattern)

Some examples of ValueObjects• Email address• Price (Amount + Currency)• ID• Country Code• TestScore• Discount• Perspiration

NB: Usually you would not use a ValueObject to represent a user, since a user can change state. User should be an entity that uses VOs internally.

Quick Recap:

ValueObjects . . .

• Encapsulate a self contained value• Allow you to guard against bad input• Represent the value, not the data within• Are immutable• Make code and system design much easier, leading to

more structured system that’s easier to maintain.

More readingIf you’re interested in learning more about this pattern and others like it, I’d recommend looking into “Domain Driven Design”, specifically Eric Evans book.

It’s a how-to book on using this pattern and others like it to build large scale, distributed micro-services.

Thanks for listening

Any questions?

Barry O Sullivan – barry@tercet.io - http://barryosullivan.me