The Strategy Pattern

The standard dictionary meaning of strategy: it is a plan of action designed to achieve a specific goal/target.

If I want to reach the office I will ride my bike and reach the office, I will call it Strategy-1. But these days petrol is very expensive and I am running out of money so to tackle this problem, I can use the train to solve the problem and I will call it Strategy-2. But now I found that train takes more time or it gets late most of the time so the next way to solve this problem is using the bus to reach the office I will call it Strategy-3.

So what happens above is, I am deciding the way to reach my office depending on the current situation.

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. -Gang of Four

Let’s take a look at another example. Our grill depends upon the strategy to tell us what type of food is to be grilled. It means that at runtime we are able to decide the type of food to be grilled.

Now, let’s get the grill ready.

Now let’s get grilling! We’ll start with some sandwiches.

These sandwiches are almost done, time to throw on the burger and veggie patties.


We were able to switch out items without creating a new class of Grill. We  are not creating a new separate class for each new food item. That's how we avoid writing more code by using strategy pattern and combining components and writing a new class for every type of grill would become unmaintainable quickly.

Praveen is an engineer at C42 Engineering. If you liked this post, please consider...


Syncing with Webhooks

Data or State Syncing is a hard problem. It often appears to be the root cause of most bugs. It also has some overheads like timestamp correction and network overload. Webhooks seems like a good strategy for tackling syncing problems and its overheads. The term webhook was coined by Jeff Lindsay in 2007 from the computer programming term hook.

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the
originating website or application.
— Wikipedia

Callbacks are basic HTTP POST URLs accepting XML or JSON data. Callback maintainers can process this data any way they want to.

 Consider a scenario of syncing Orders between two applications (say P and Q). Where P is a major E-Commerce platform with millions of orders every day. And Q is a fraud detection backend where humans intervene. An Order cannot be Confirmed unless it's Verified by a human. Here the big overhead is human element of the process which is slow but necessary. In the near future this human verification will be replaced with Machine Learning algorithms once enough data is collected.

Syncing of an Order will happen as follows,

  1. An Order Request with Callback URL will be sent from P to Q.
  2. The Order Request will be processed at Q using human counterparts.
  3. Q will mark Order Request as Verified or Rejected.
  4. If Order Request is Verified, send an HTTP POST with verified data as payload to the Callback URL.
  5. If Order Request is Rejected, send an HTTP POST with rejection reason as payload to the Callback URL.

Syncing of Order may seem like a simple posting and waiting protocol. But it has some minor tweaks. You can also use any amount of magical sauce in it like dispatching callbacks in batches or using pooled async calls.


Webhooks were inherently designed to handle

  • Notifications
  • Real-time data synchronization
  • Process data & repost it
  • Data validation checks

In this post, we've exploited the process data and repost it design feature of webhooks. You can use webhooks for a variety of different use cases.


Ranjeet is an engineer at C42 Engineering. If you liked this post, please consider...


Code Smells : Copying objects

While copying a two dimensional array in Ruby, both Object#dup and Object#clone were creating the problem of “shallow copying”. Separate copies of the array elements were created but the same reference for any Object type attributes were used inside the element. Hence, any changes to objects inside one array were showing in the copied one as well .

A solution to shallow copying seemed to be Marshal. Forums were littered with caution against the usage of Marshal for copying. I ignored the warning and enjoyed a working output from my implementation of Conways's Game of Life. This is how Marshal was used:

@cell_grid = Marshal.load(Marshal.dump(@new_grid))

I introduced objects (instead of strings) as constants inside the Cell class that was used as the basic element of an array.

The output started behaving in an unpredictable manner and I was stuck for hours before giving up and asking for help. Turned out, that the way Marshal works is that it serialises and deserialises the objects DEAD and ALIVE and thus changes the object id.

So how do you solve the issue of copying objects or data structures in Ruby after having being let down by Object#dup, Object#clone and Marshal? The simple answer is – you avoid copying! This may sound too harsh, but as pointed out :

“generally, if you’re trying to make a copy of an object, you’re probably thinking about the problem wrong. Copying can be avoided by exploiting the way ruby references work and designing the function APIs accordingly”.

Gregory Brown, author of Best Practises in Ruby

Inspired but still dubious, I set out to remove any instances of copying in my Game of Life implementation. Instead of copying the two dimensional grid, I changed the state of the grid for the next generation based on the current generation's grid.

We intutively use copying in our code for situations which might seem like they need copying. But reducing instances of copying will ensure less buggy code base.

Aditya is an engineer at C42 Engineering. If you liked this post, please consider...