Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Is this a known design pattern: a piece of code is responsible for acting as a central proxy for data distributed in various places?
I have several classes (C_1...C_n) and their instances (I_1....I_m). I have a "Registry" R of these.
There are several pieces of data (d_1...d_k) spread across various instances. This much is set in stone, i.e. I consider the data being spread across the instances as appropriate design.
class Server { // C1
public String host; // d_i
public String port;
//....
}
class Administrator { // C2
public String username; // d_j
public String hashed_password;
public Server belongs_to;
//....
}
// ....
class SomethingElse { // Cn
// more of this later
}
class RegistryOfWellKnownInstances {
getServers(); // I_j
getAdministrators(); // I_k
// ...
}
Now while writing the code in C_i, each class does know how to access the data that it's responsible for (among the d_j), but I wouldn't like it to have that knowledge for the data in other classes / instances.
/**
* Let's say there's a concept of certain well-known instances with the Registry. There are servers "testing" and "prod" and we want access to the host name (d_i) and admin usernames (d_j) for them.
* This class doesn't have too much knowledge about the `Server` class or `Administrator` class. They are complex classes, and perhaps managed by another set of programers. It doesn't even care about how/where these instances are created and how it'll have access to those instances.
*/
class SomethingElse {
// ...
}
I'm thinking of achieving this by declaring a singleton class X which has access to this registry, and it acts as a proxy between the actual location of the data (in I_j) and the name of the data d_k.
// I could directly encode logic for getting the data from the registry in the class "SomethingElse", but it's actually needed by others as well, so let's define something common
class X {
// NOTE: I'm aware that I can parametrize this with "prod" or "testing" but for sake of example let's say these are simple getters without a parameter.
// These methods would work by essentially getting instance from registry and just invoking appropriate getters / accessing appropriate fields
get_prod_hostname() // d1
get_testing_hostname() // d2
get_prod_admins() // d3
get_testing_admins() // d4
// ....
}
So using X, anywhere in my program I can write X.get_d2() and I'll get d2, without worrying about where it came from.
Is this a known design pattern? If not, then are there any obvious pitfalls with this design that some other patterns are known to mitigate?
1 answer
General information
As indicated in the comments you are looking for something similar to the Facade pattern. It is still not clear what you are trying to achieve, but the X class seems that it will tackle way too many things.
In order to avoid adding a lot of logic in one class (even if it only acts as a facade or proxy for other functionality), you should consider splitting the application logic in a way that makes it more maintainable. An example of architecture that does the job very nicely is the clean architecture (implementation example).
The idea is to split the logic into use cases so that there is a very good match between the business requirement (use case) and how the logic is implemented. The aforementioned example solution relies on a CQRS implementation that does this separation.
Your case (as I can guess from the provided code)
Each use case would be mapped to a class that injects only the dependencies it needs. Examples:
- run automatic tests in a test environment relies on getting server data, getting credentials for that server and a test runner
- running some tests in prod relies on getting production server data, getting credentials and using a smoke tests runner
Of course, if a scenario applies to all environments, it can receive an environment identifier and act both on test and production.
I know that this is not a direct answer to your question, but I think that such an implementation (or similar) would ensure a good decoupling (e.g. some testing environments functionality should never be run in prod) and increased maintenance (e.g. making changes to test related flows is less likely to mess up with production only flows).
0 comment threads
1 comment thread