Forem: Daniel Mwakanema

One Design Pattern Per Day (Day 2)

Daniel Mwakanema — Tue, 07 May 2019 19:31:55 +0000

A little context

A few steps back in time, a client "discovered a way" to make more than what was marketed by a certain pyramid scheme. Essentially, con the con-men.

The scheme has a site through which you can create accounts for a fee and if a certain criteria is met, you get rewards. As expected the whole process builds, you guessed it, a pyramid.

I accepted, mostly due to interest in implementing the solution, :).

NB:

Anything that needs further explanation has a link attached to it.

Approach?

Site has no API-like entity so I chose Headless Browsing using Nightmare.js.
Persistence with MongoDB using the Adjacency List Model.
REST API in Node.js because there is also a React application the client needed.

Problem for the day?

This one is a bit trivial. The requirements specified a number of ways to build the pyramid and under certain conditions the application needs to switch between these ways. Essentially, switch its behavior. So having seen it before I thought I'd use the Strategy Pattern.

For this application I am using JavaScript which is dynamically typed and from my small knowledge does not have constructs like interfaces so we'll follow the let-it-fail ideology in the case that a strategy is given that does not implement what we expect.

How am going I to implement it?

Create Strategies using the Revealing Module Pattern. You could do this using a Function constructor as well by attaching accessible members to this.
Create a Context function that uses simple dependency injection to receive a strategy and alters its behavior with the change in strategy. The Context I assume provides a recognized point of access to our 1..N strategies.

The application then chooses strategies and accesses them through the Context. Again I did not run this code, not sure why.

The strategies:

const StrategyB = _ => {
  //more private members here

  function execute () {
    // do stuff in here
  }

  return {
    execute: execute
  }
}

const StrategyA = _ => {
  // more private members here

  function execute () {
    // do more stuff here
  }

  return {
    execute: execute
  }
}

The context:

  function Context (Strategy) {
    this.strategy = Strategy

    this.execute = _ => { this.strategy.execute() }
    this.setStrategy = strategy => { this.strategy = strategy} 
  }

Usage:

  const context = new Context(A_DEFAULT_STRATEGY_OF_YOUR_CHOICE)
  if (SOMETHING) context.execute()
  else if (SOMETHING_ELSE) {
    context.setStrategy(StrategyA())
    context.execute()
  }
  // ... and the ladder goes on

I had a bit of trouble with this one but to me using this pattern allows me to independently implement each strategy while worrying less about writing messy code. With time I may gain more insight into it.

One Design Pattern Per Day (Day 1); Also first post

Daniel Mwakanema — Mon, 06 May 2019 06:15:52 +0000

For the why?

Well design patterns are not really a strong point of mine and naturally to get better we have to do. It will not be perfect so your criticism is welcome.

Problem for the day?

In recent times I got the chance to watch another developer work. The developer was writing an application that talks to a particular API. The API had recently undergone revisions and upper-management wanted the application to be able to talk to both versions depending on the deployment configuration.

How did the developer solve the problem?

The developer used the if control structure under each route in the application to execute the appropriate code for three versions of the API.

Perceived issues with approach?

Very long and bloated functions
Hard to understand code
Too many levels of abstraction under each route

My thoughts?

From my point of view, the problem involves selecting an API version and from that creating the appropriate API instance. Seems like it could fall under class instantiation and object creation.

How I may have done it (the instantiation at least)?

Create an interface that defines the API
Have any version implement it
Create a factory to create the appropriate instance given a version

So erm, the code would look like the following (there may be errors, don't care):

The interface:

  public interface API
  {
    public void doSomething();
    public void doOneMoreThing();
  }

The API instances:

  public class ApiV1 implements API
  {
    public void doSomething()
    {
      // doing something
    }

    public void doOneMoreThing()
    {
      // doing one more thing
    }
  }

  public class ApiV2 implements API
  {
    public void doSomething()
    {
      // doing something but slightly differently
    }

    public void doOneMoreThing()
    {
      // doing one more thing but slightly differently
    }
  }

The factory:

  public class APIFactory
  {
    private Map<String, API> apiMap =  Map.ofEntries(entry("v1", ApiV1),
                                                     entry("v2", ApiV2));

    public API getApiIstance (string version)
    {
      if (!this.apiMap.containsKey(version)) {
        throw new IllegalArgumentException("Passed API version does not exist.");
      }
      return this.apiMap.get(version)();
    }
  }

Usage:

  // assuming there is a config somewhere
  API apiv1 = APIFactory().getApiInstance(config.apiVersion);

Conclusion:

So erm, yeah. Not perfect but perhaps a step in the right direction.

Hi, I'm Daniel Mwakanema

Daniel Mwakanema — Mon, 10 Apr 2017 08:22:33 +0000

Hello there, I am currently a code monkey in the industry focused on becoming an intermediate beginner.

I love JavaScript but also dabble in Ruby and PHP. My Git dwells here, Daniel Mwakanema.

I am currently learning Go and advanced JavaScript.

As you were.