Coding is poetry, Design Pattern is the Philosophy.

Coding has evolved a lot from the stage of ‘instructions to the computer to perform a certain task’. As the code is written once and read so many times, along with getting things done, coding is also seen as a medium to express logic in an elegant way. In the opinion of a lot of developers, the code should read like a story, a person who is reading it should understand the logic underneath when skimming through it. Sometimes the nasty devil within developers makes this story so complex (believe me, many people do this purposefully) that the developer himself can’t understand what the code does when he comes back to the code after 3 or 4 months.

The code has to be expressive and meaningful

Rather than saying a developer is engineering a piece of code, many people would say a developer ‘writes’ the code. A lot of the developers consider coding as an art. Like any other form of art, the code should be ‘expressed’ rather than ‘written’. The purest form of artistic expression is poetry. So it would make sense (at least to some people) when I relate coding to poetry. Poems which have a very good rhythm and convey its meaning to a reader is always a pleasure to read, code that would convey its meaning in an elegant way is also beautiful and it is always a pleasure to work on.

It makes a significant impact when you write code just to do a thing and for the sake of it and when you try to express your logic with the code as a medium to communicate.
In the former method, a person who is reading the code in the future to understand what it does will have to travel through the very logic that you tried to put in there. He will have to think through all those nested loops that you have put in and evaluate the conditions that you had put in between the nested loops. To be honest, your comments on the top of the code isn’t going to help him much. This could be a simple story, told in a very very confusing way.

Let’s look into a simple case and see how it feels

Consider a class Student with roll number, name and an array of subjects.

Student.java

Each subject would contain the name of the subject, marks scored on that subject and the name of the teacher who is teaching that subject

Fair enough, now I have a static method getStudents() that would return a populated

Student[] with enough data.

Let’s consider a problem.

From the list of students, we need to identify the students who failed in Maths and Physics and schedule a meeting with the teachers who are teaching it. So the teacher names who match this criterion will be printed. Pass mark for the subject is 40.

I’m using Java to solve this.

I would roll up my sleeves and look at two things, what I have got, and what needs to be done.

Well, I have got an array inside another array and got a couple of conditions to evaluate, so here is what I need to get this done.

Here I am trying to solve the problem, however, I am failing to tell the story to the person who is going to read it. And this piece of code to another developer is not a story or a poem but a small puzzle to resolve. I’m sure that if I have to come back this code after a few months to make some changes I’ll have to look back and forth a couple of time to figure out what exactly this little piece of code does.

Now I am trying to refactor the code so that it expresses its own logic.

When I try to read the code now, it tells it is streaming the student list and for each student, it is taking all his subjects and filtering it down to the required values.

Along with doing what it is intended to do, the code also explains what it is doing, it will take less time to understand and maintain the latter piece of code.

The definition of the lambda expressions in the above example, given below.

With functional programming capabilities of the language that you use, you have enough flexibility to express your logic.

Whether you are working with transaction management, report generation, image processing or enterprise integration, your code can always be expressive and be beautiful as a poem.

Philosophy of Poems

There are cute little poems that would carry an intense philosophy. It goes deeper than the literal meaning and is something to think of.

In software engineering, we might need to make every solution as reusable, extendable and scalable as possible.

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

When we write code as a solution to a problem, and we are addressing it in a pattern that can be applied on similar solutions, the meaning of the code goes beyond what it is written, it also gives insight on how to extend or scale the solution in the future.

Let’s consider the below problem.

Imagine that you have a list of files that need to be compressed and you have two different compression techniques to apply. One for small files and the other one for the large files.
The size of the files may vary, and depending on the size, you have to apply the appropriate compression technique. This could be done in different ways. One way of doing this as follows.

In this way, the list of files is iterated and based on the threshold file size relevant compression technique is applied. This method would do the task but I wouldn’t consider it to be maintainable or extendable. If there is a new compression technique for very large files it will be difficult to ingest that logic into the existing code.

To solve this problem, let’s think in terms of the Strategy Pattern.

Let’s have a CompressionStrategy interface and concrete compression strategies implementing it. Also, we can have a CompressionContext which returns the suited compression technique depending on the file size.

Proceeding with this, we have a mechanism where we could add any number of compression techniques as implementations and code where the compression is called will not be affected.

From the code, the compression technique will be chosen as below.

This code will remain unchanged even if more compression techniques are introduced into this environment.

The latter method has not only got a meaning but a deep insight as well, which is rooted in the philosophy of strategy pattern. When this code is handled later by a person who is familiar with this particular pattern it takes very little time for him to extend this mechanism if needed.

Coding is poetry and Design Pattern is the philosophy.

Originally published at thephilosophyofcode.blogspot.com.