Design Patterns for Different Client Code Behaviors

Architecturecdesign-patterns

At my company, we have a solution composed of a WinForm (multiple per client) and an API (one per client). This solution is deployed on different clients that require the solution to behave differently according to their desires. The same code base must support UI customizations (client logo, buttons visibility) and functionality customizations (calling the same WebMethod with different flags).

Currently we manage this flexibility on the WinForm side by having an Organization class that contains all these customizations (flags). The API is totally client-agnostic. Thus, the WinForm's methods look like this:

this.Logo = CurrentOrganization.LogoImage;

API.GetProducts(Organization.UsesPagination);

In the past, we had conditional build directives scattered among the code:

#IF CLIENT_A
    API.GetProductsWithPagination();
#ELSE
    API.GetProducts();
#ENDIF

Today, we have a single zone with those conditional build directives that, according to the build configuration, instantiates the required Organization class. Afterwards, there are no more IFs, parameter passing.

I'm a bit worried this is not the best design or the most maintainable solution. I studied the State pattern… I guess the Organization is my strategy object, since it tells other methods how they should behave through flags.

Is there a better way?

Storing configurations on a DB table? (requires more requests to the API, which costs time)
Storing configurations on a *.config files? (someone can easily change the app behavior by editing the file)

Best Answer

First thing you should check is how many lines of code a typical Organization class implementation has, and how it is structured. If it has less than 100 lines of code, and the class consists mainly of properties providing some flags or data, do not worry. If it has more than 2000, and it contains a lot of business logic, you should consider to split it into smaller pieces, or to generalize some flags or properties. Nevertheless your Organization class can still be a facade to the configuration data.

Storing configurations on a DB table? Storing configurations on a *.config files?

Even if you use a DB table or a configuration file, you will still need an Organization object which loads the configuration from the DB table or configuration file into memory to provide those data to the rest of the program. This enables you or an admin or someone else to add new organizations, or to change features of existing organizations without actually changing the code. So use a DB table or a configuration file if you have that requirement - not because you want to achieve a better maintainability.

Related Solutions

Design Patterns – Differences Between Facade Pattern and Abstraction Layers

The relationship between the two: The Facade pattern is a subset of "layers of abstraction". A Facade is an added level of abstraction. Not all abstractions are Facades.

Specifically, a Facade is where we offer a simplified interface to a complex API. Sometimes we are wrapping numerous complex classes in one simple one; sometimes we are just taking one class with a complex API and simplifying it for the calling code.

If you are simply forwarding one call to another class with the same interface, that is more accurately the Proxy pattern. This is another type of abstraction layer.

Is it a good idea to abstract logging out in an MVC pattern? Yes (most MVC frameworks will do this for you). But whether you should be abstracting it using a Proxy or a Facade depends very much on the login API.

Design Pattern: Algorithm varies according to the input arguments

It's not clear to me that you need any design pattern -- at least not in the sense of the "Gang of Four" book.

From your description of the problem:

Every combination of arguments needs a different algorithm

what you need is some way to get from input -> output where input is "combination of arguments" and output is "algorithm". This is essentially just a hash table (or a function), in which:

keys: some property of the specific arguments present
values: algorithms (the exact implementation could be functions, objects, etc. depending on which language you're using and how convenient each choice is).

The second part of your problem -- "The .createBuffer method has required and optional arguments" -- isn't well-specified enough to give a sure answer, and will also depend on your choice of language. If your language supports optional arguments and default values, this problem nearly solves itself:

def createBuffer(self, radius, direction="outside")
    ...

If you're in Java, you can use reference types and check for null, converting them to default values where necessary. Or even better, try this -- it helps clarify your intention to use nullable types to other programmers!

public void createBuffer(float radius, Optional<Direction> direction) {
    if ( direction.isAbsent() ) {
        direction = new Direction("outside");
    }
    ....
}

As others mentioned, you could also throw the Builder pattern at it, but personally I wouldn't unless I was sure that I needed it, because a single method with a single type signature is simpler and easier to use.

Best Answer

Related Solutions

Design Patterns – Differences Between Facade Pattern and Abstraction Layers

Design Pattern: Algorithm varies according to the input arguments

Related Topic