Are Design Pattern and Clean Code Useful?

Photo by Fotis Fotopoulos on Unsplash

I overheard our junior developers discussing the value of design pattern and clean code. I vaguely remember their conclusion is, “those techniques make simple things become complex, and that is the favorite thing of those technical authorities who are far from the reality”. Their discussion ends up a negative agreement.

There are some examples from their conversation. For instance, in clean code, the length of a function is limited in a regular size, which results in to overlook a whole function’s functionality, it has to dive into several nested sub-functions. Besides, design pattern ask us encapsulate a simple task into an object, and the objects are everywhere. Coding with objects will make the source code much more longer.

Well, I can understand their pain points. Those pain points come from some reasons such as

1. Their duty is quite simple without too many complicated design or further expandability needs.
2. In a small organization, they don’t need to consider the cooperation. All features are handled by a few people.
3. They don’t realize the concepts of those paradigms, instead, they just see the “tricks”.

If I were in their position, I perhaps agreed with them. Nevertheless, I had not joined their discussion. After all, I am more close to an authority for them. But, I have to say in their mentioned examples, those methodologies have its meaning.

Firstly, restricting the function length must be combined with a well-defined naming convention and a good parameter design to let everyone understand what’s the purpose of this function without traversing the detail implementations. Secondly, encapsulating objects is to accomplish a better abstraction and become easier to achieve Open-Closed Principle. Whether encapsulate logic in Strategy Pattern or encapsulate the creation in Factory Method, they make developers be able to use the existing code without reinventing the wheel. In addition, developers can extend the functionality more easily.

Design pattern and clean code provide some tricks and principles, however, the most important thing is the spirit and purpose behind them. For example,

if prop == 1:
    do_a()
elif prop == 2:
    do_b()
elif prop == 3:
    do_c()
else:
    do_default()

This simple example can be considered that those do_XX are some flatted source code. Those junior developers would like to see those behaviors clearly on the same code level like the above python example. In order to understand the implementation at a glance, actually, there are many a way to do better.

func = {
    1: do_a,
    2: do_b,
    3: do_c,
}
if prop in func:
    func[prop]()
else:
    do_default()

Through simple packaging, it is easier for people who want to read the code to understand the purpose. They can inquire about the part of details they want to see by themselves. In addition to add a new feature, developers just need a handler in func. Furthermore,

factory.create(prop).run()

By adopting the factory method, the function become more slim. The cognitive load for readers is low as well. In fact, this piece of code encapsulate the logic in polymorphism to run, aka, Strategy Pattern. It is unnecessary to talk about these details implementation of design pattern or clean code. Once you understand his spirit, you can easily have your own implementation. In the above example, it is indeed not a “standard” factory method implementation.

After skilled design pattern, those pattern names just provide a common language between developers, so that they can communicate more smoothly. For instance, “I have done an observer pattern over here”. It is no need to explain further that you can realize there are a subject and an observer with attach and notify. Even no documents, you still can understand the prototype of the code in your mind.

The purpose of coding is not only making features but also be a communication tool. Clean Code said, “Don’t document your code. Code your documentation”. But these can only be experienced after those junior developers have written about larger functions, cooperated with more people, and met more changing requirements. Everyone chooses a different career path, and not everyone has the opportunity to enter the world where the design pattern and clean code are facing in.