TNS
VOXPOP
AI-Aided Coding
On average, how much time do you think you save per week by an AI-powered coding assistant such as GitHub Copilot or JetBrains AI Assistant?
I don’t use an AI coding assistant.
0%
Up to 1 hour/week
0%
1-3 hours
0%
3-5 hours
0%
5-8 hours
0%
More than 8 hours
0%
I don’t save any time, yet!
0%
Software Development

An Introduction to Software Registration for Web Developers

Registration is a pattern that allows developers to add a component to a formal list at runtime. This post shows how useful this pattern is.
Sep 18th, 2023 7:16am by
Featued image for: An Introduction to Software Registration for Web Developers
Image via Unsplash.

Development is a dance between code and data; we want the flexibility of data descriptions, but the certainty of coded solutions. Relationships between objects are rich, but dependencies cause issues.

Registration is a common pattern that allows developers to add a component to a formal list at runtime, allowing erstwhile data to participate in code.

So a register is just a list of objects that the app treats as canonical, with a few caveats. We almost certainly don’t want replication, which implies we need some sort of primary key. It also implies there is some sort of raw list of data that seeds this register. Like many patterns, the advantage to using registration is that it is a good way to separate concerns. This post shows how simple but relatively useful this pattern is. You can follow the C# code, or clone it from GitHub.

Via Paul Downey, UK Government Digital Service

The concept of a hardware register slightly overshadows the simpler concept of software registration. But we do see registration quite commonly when using APIs — for example, you often have to register listeners to events when programming buttons in UI.

A more formal description of a register isn’t necessary for this post, but for completeness have a look at what Paul Downey wrote here, and also Ade Adewunmi for the renowned UK Government Digital Service. A few useful tenets are repeated: each registered object has a unique identifier; data replication is to be avoided; allow registers to talk to other registers; and treat registers as trusted data.

I hope many readers have had the chance to go on holiday this summer, and the simple example I give of registration is just a summer-themed matching of a party of holidaymakers to the right-sized cabin. So we have two registers: cabins and holiday parties.

Let’s take a look at the details:

  • A “cabin” has a door number (primary key) and a capacity that represents sleeping space. It also has a date range when it is available.
  • A “party” represents a number of holidaymakers under a lead traveller’s name.
  • A party can only book (i.e. registration) into a cabin if the cabin is vacant and available.
  • As a party can only be registered with a vacant cabin, there is a natural dependency in this model.
  • If you unregister a party, their cabin becomes vacant. Consequently, you can’t unregister a cabin if a party is staying in it.

To represent all cabins, we use a JSON list called “allcabins.json”. We iterate over this list, and only register cabins that are available during the date we are interested in.

Similarly, we have a list of prospective parties; we iterate over these holidaymakers, only registering parties when we can put them in a cabin. We should do this before they arrive, to avoid disappointment.

The other thing of interest is that registered objects interact with other registered objects when the party checks for available registered cabins. We would normally prefer to unregister an object as opposed to making changes to a registered object.

Cabins

The cabins that lie in our wild resort are represented in a JSON file, allcabins.json:


Note we will use the cabin number as the primary key. The From/To date format for availability is represented as a string, as it has to be for JSON.

After sucking up the JSON data into its own CabinData struct, we create a Cabin object from it after converting the string dates to C# dates and adding a guestParty variable to note who, if anyone is, staying:


The JSON file is handled elsewhere. But the result is that we can make cabins from raw data.

So where do we register them?


This is mainly just a gatekeeper to the registeredCabins list. We fulfill two requirements: we don’t allow a cabin with the same number to appear twice, and we check that the cabin is available for the date given. When unregistering a cabin, we check there are no guests already staying.

Holiday Parties

Now for the other register: the guest holiday parties. The JSON data is just the name of the party and its size. So it leads to a simpler object:


While a cabin may be vacant, a Party object must be associated with a cabin once registered — hence we don’t suggest it is nullable.


Again, registration just sits as a gatekeeper, this time making sure that a party has an available cabin of the right size to stay in.

Finally, here are the console responses to our calls from the main program:


The project code is available on GitHub here. If you want to improve the functionality of the code, maybe you can better fit the party size to the capacity of the available cabins.

Group Created with Sketch.