{ JS } w/ Job

Garden Website: The Repository Pattern

Last Modified: August 08, 2024


TL;DR

Given we'll support different peripherals - each with their own models - and each peripheral would require similar things such as access to a database and an API endpoint, use interfaces or abstract classes for the specific peripheral to inherit from rather than manually implement all of the databse and api stuff for the peripheral. This will make supporting new peripherals require less code in the long run.

Background

Since my previous plant project post ( sometime mid-April ), I landed my first paid software related position at ⛓️Canvas Credit Union.

While at Canvas, I worked on was building internal APIs using :

With this, I practiced different approached / patterns to building APIs. ( More on this coming soon! )

Terms / Symbols

The Repository Pattern

General Example

Example using a temperature sensor

Repository pattern with Temperature Sensor and Water Pump

Why use generics?

I have various entities such as temperature sensors, and an actuator like a water pumps. Each of these entities requires CRUD operations and interactions with my database and API.

Leveraging generics would allow me to use the same interface for different concrete implementations that support different types of sensors / actuators. In other words, without generics I would need to implement multiple un-instantiateable pieces of code - this works against my goal of building reusable code.

Why use abstract classes instead of interfaces?

Both abstract classes and interfaces would ensure enforce inherited method gets implemented. The difference between the two is weather or not the concrete class is required to provide its own implementation detail. With abstract classes, you'll inherit the detail whereas with interfaces you won't.

For my useage, I'll have a lot of boilerplate implementation detail with a few details to override.