The Repository Pattern — The Pattern for Componentization
As a software architect, I study the creation of software. We talk about abstractions beyond the given problem domain. We dream about what lays beyond the problem. What is the fundamental essence of the problem at hand? What is the best way to solve it at this time? Every architect knows these questions. It is what makes us the modern day practical philosopher.
Architects look to patterns, components and frameworks as tools to implement the solutions to those problem domains. Each tool is a degree of abstraction that wraps complexity and is proven to a degree. This allows us to forge ahead. With those tools, we build on the experience of other software engineers. Like cooks that follow a recipe but are adding their own twist.
What is the repository pattern?
The pattern is simple. It’s a class or a module that hides variables from being directly used. The get/set functions that we all were told to use in object oriented classes. We learned to do that because the way the variables are derived often changes over time. What were constants become variables dependent on configuration. A perfect example are gui strings. We learned quickly that to support multiple languages it was best to access the string by some type of function. So the repository pattern is simply a collection of accessors to all the variables/state and constants a component uses.
So what does that do for a component?
By using the repository pattern the component is split into 2 distinct elements: the data that interacts with the component not directly passed to the function (data model) and the functions that are the essence of a component (functional model). To test a functional model you vary the data passed in to the function and the data in the repository. What sits behind the repository could be a database or a simple collection class; it all depends on the size and scope of the application.
The repository creates a schema of data needed to support the component. The collection of all the component schema, can define the state of the problem domain. The application that glues everything together is a component of limited reuse value.
Cool so far, right? But it gets better. If you assume a repository works on a reference to a simple collection of data like a dictionary or map, standard collections supported in all modern languages. That collection can be injected into the component or the component can generate a default state.
By passing around a language’s default collection you create a loose coupling between components. Loose coupling allows for maximizing reuse of functionality. It also means a component can be encoded in whatever modern computer language you choose. The components concepts easily move across physical architecture layers.
And let us just say if the component contains a highly complex function, all its data inputs have been isolated, therefore the functional model begins to look like a node in a machine model. Machine models are just functions all the way down… So the entire functional model could be replaced by a set of machine models.
Just think about that and its implications to how we develop software.
