One thing I’ve been interested in recently is Domain Driven Design – I’ve not really read into it in depth but from conversations with friends and colleagues I feel I’ve understood at least the high level concepts.
I’ve thought for a while now that it’s time for me to create my own app, if for no other reason than to prove to myself I could do it. I’ve been working on a couple of things with a couple of friends/colleagues but due to limited time, and the fact that they’re quite large projects, progress has been slow.
Last week, I attended an LSCC (London Software Craftsmanship Community) open space, hosted in the Codurance offices for the first time! We celebrated LSCC’s 6th birthday (so there was cake – my kinda meetup!) and a very decent vegetarian pizza. But, this isn’t a food blog so let’s move swiftly on…
It started out with some interesting lightning talks, we had someone talking about communities and how the culture of a community defines that community; we had another talk introducing the some of the concepts of DDD; some people describing their company’s transition from horizontally aligned teams (one in charge of the database, one in charge of the UI, etc) to more feature aligned teams (where every team had the expertise to deliver a whole feature, front to back); just to name a few!
While reading up on builders to write these posts, I came across an interesting blog by Per Lundholm which demonstrated another builder pattern that can be used. This solves the problem of having some fields which are optional and others which are mandatory. As it stands, we are treating all fields the same in the builder, and introducing any specific behaviour we want to for optional fields when we construct the object.
To make data immutable, it must be set the moment the object is created, i.e. in the constructor. However, as we’ve seen in the introduction post, adding the data into the constructor directly comes with problems of its own – having multiple arguments in any function increases complexity and makes things confusing.
In the previous post, we were introduced to the concept of a builder, and showed how to construct the object we wanted in a way where the resulting code was easy to read and understand.
Is there a way to combine the two concepts above so that we can use a Builder to create an object where the fields cannot change their values? YES!
Let’s review the problems we faced with the previous two methods of adding data to our Wizard object:
- The constructor required us to add all of the fields every time we created a new instance of the class, or requires several different constructors. This is fine when there are only one or two different fields – but increasing the number of optional fields exponentially increases the number of constructors required. In general, we don’t really want to have massive constructors with lots of arguments passed in anyway, as it reduces readability and increases complexity, both of which are undesirable as they make the code less maintainable.
- The setters allowed us to set as many fields on the object as we wanted, but it can make things confusing because we can set things directly onto the object in different places in the code. It is easy to forget or lose track of what has already been set. It is impossible to make the fields immutable with setters, by definition if there is a way to set the data whenever we want to, it is modifiable.
There is a way to add data which solves both of these problems.
Often, we need to create objects that store data. There are a few different ways to do this, and I will be looking at the pros and cons of each in the next few posts.
There are a few considerations we need to think about when deciding what method we want to use:
- How many fields are there in total that need to be added?
- Are they all mandatory? If not, what should be the default behaviour if an optional field is not populated?
- Do we want the data to be immutable? I.e. once it has been set on an object, can it subsequently change?