Primus2\Falcraft: Registry Design Pattern
I’m proud to announce the implementation of a Registry design pattern in primus/falcraft
The Registry Pattern
To quote Martin Fowler:
When you want to find an object you usually start with another object that has an association to it, and use the association to navigate to it. Thus, if you want to find all the orders for a customer, you start with the customer object and use a method on it to get the orders. However, in some cases you won’t have an appropriate object to start with. You may know the customer’s ID number but not have a reference. In this case you need some kind of lookup method – a finder – but the question remains: How do you get to the finder?
A Registry is essentially a global object, or at least it looks like one – even if it isn’t as global as it may appear.
The global registry pattern in primus/falcraft is mainly for aggregation of singleton implementations. In this sense, a feature or functionality is put under a key name (such as the fully qualified name) which is then accessed elsewhere in the program. The registry itself is a singleton.
For example, take a singleton such as a file system access library. A operating system file access singleton is written. Later we want to use a file access singleton that operates over any abstract filesystem, including cloud based ones such as AWS or DropBox. If the file access singletons provide the same interface, we can take the old singleton out and put the new singleton in under the same key (such as say, ‘\file\access\abstract’) as before. Now we have an abstract file system singleton without changing a line of code elsewhere, such as changing the class name or fully qualified namespace.
Applications include anything that singletons could also be used for, such as registering a central key for an autoloader or logging system. The ‘key’, pardon the pun, is the key identifier to the singleton rather than the singleton hardcoded in the source.
NOTE: This required a change in the SingletonTrait that included ‘un-finalizing’ the constructor function so that Registry could override it per being a descendent of \ArrayObject. As well, this increases the functionality and flexibility of the SingletonTrait. An added structure is the SingletonInterface that mirrors the provided functions in the SingletonTrait. This can be used to dynamically determine Singleton status or behavior since the trait is not inherited.
View on GitHub