Design Patterns

Some patterns from functional programming paradigm.

Anti-pattern

The Gas Factory or Unnecessary complexity.

Just as in any system, when you start coding some structure, you always try to make it as generic as possible to make it easy to later reuse those parts.

If you built a pipeline component to calculate discount but you only have one discount at the moment, it might be actually relevant to implement it anyway since you are sure you might require it later. However, the client is the one that is supposed to drive the requirements and if you don’t require the pipeline immediately… well… don’t build it!

It doesn’t mean leaving your code in a fixed state. It just means keeping your code clean to ease the implementation of the pipeline.

The best line of codes is those we don’t need to write.

God object: too many functions are concentrated in a single part of the design (a certain class)

The code must be easily maintained, enhanced and debugged when problems happen. One of the reasons why object-oriented programming is so popular is because it delivers on these requirements.

But anti-patterns often appear when developers take shortcuts or focus more on the need to get things done instead of done right. One of those common anti-patterns is the God object.

The God object violates the single-responsibility design pattern because it:

• performs multiple tasks;
• declares many unrelated properties; and
• maintains a collection of methods that have no logical relationship with each other.