Get familiar with different programming paradigms

In this article, lets discuss different programming paradigms, their pros and cons and design considerations to choose for your application.

Object Oriented Programming Paradigm:

This is the classical paradigm which is tested its time and is still considered one of the preferred way to design applications. In the paradigm, Objects are the first class citizens and interaction between objects to accomplish the different use cases. The key consideration here, is that during the execution of the flow, the state of the object changes. i.e. the state of the object is mutated over the flow and this series of state changes makes the transition of the object from initial state to final state.

This is very intuitive approach if we consider any normal use cases in real life. Lets take an example of preparing a cup of coffee. First we take the milk, boil it, then add sugar and still and finally add the coffee powder and prepare the coffee. At every action, the state of the milk changes to its final state of transitioning to coffee.

Now, lets understand the pros and cons of this approach.

Pros: This is very intuitive approach to solve a given use case. This form of decomposition of the given problem set is also easy to understand, follow, maintain the code and troubleshoot the issue.

Cons: Shared state of objects means, shared data and hence, care should be taken when designing application to leverage concurrency. If an object can be mutated, then we need to carefully design and take care of concurrency failing which, we run into serious bugs which are difficult to reproduce, test and fix. This also requires for developers to have a good understanding of implement correct concurrent programs and rigorous discipline so they can understand each others code.

Functional Programming Paradigm:

Functional programming is also one of the popular programming paradigm. In this approach, unlike Objects, functions are first class citizens. A simple way to correlate for classical programmers is to think is, a function can be used wherever we can use Objects. i.e. we can assign a function to a variable. A function can be passed as an argument to another function, A function can be returned from a function. Also a function, can contain, of course another function.

This can be correlated with the example of a car assembly plant, where the raw material is transformed from one

form to the next form through out the process and at the end of the chain is the fully assembled car.

Although this concept is not new, the implementation in building application is being adapted recently.

We have worked with functional programming concepts when working with Unix. example: I can

view the contents of the file, then pass the content to a filter and then pass the result of the filter to

count the number of items and finally redirect the output to a file.

In the above example, the output of one operation, becomes the input of the next operation. Also, I will be able to

mix and match different independent commands. Also, I will be able to easily alter the order of the commands.

Each operation is atomic and act as pure functions. We call a function, a pure function, when a function does not cause

any side affects. This will ensure, that, we can guarantee the result for any number of execution.

Functions can be clubbed together to build higher order functions. Building higher order functions is the key advantage

of this paradigm. Using higher order function, we can build the entire application which is composed of many atomic functions.

Pros:

The biggest advantage of this style of programming is, immutable objects. If we perform

a function on an object, instead of tweaking the same object, the pure function can return a

brand new object with the new state. With this, there is no shared state and hence all concurrency

related issues can be easily solved which is a huge win as opposed to Object Oriented programming.

The other major advantage of functional programming, is the application code becomes very concise.

We will be able to create functions, which can interact with other functions, can be chained with other functions,

and hence we can plug and play different functions to meet our use case.

Also once the developers, get into the mindset of functional programming, the application code

becomes very clean, concise and easy to maintain.

Cons:

The major challenge of building a functional programming based application, is the readability.

Although, this can be debatable, the first impression of developers coming from classical background

will be intimidated with this style of programming.

The other major cons of this approach is, the result of the invocation will be asynchronous.

This will make the testing and debugging different from the traditional imperative programming approach that

we all are comfortable with.

The third point might be with respect to organization of the code which needs to be clearly thought through within

the team and the developers have to have a rigor discipline while naming the files, functions etc.

Reactive Programming:

This programming paradigm is the backbone for event driven systems. In this programming style, we have producers who publish events and the subscribers subscribe to get notified when there is an event. The project “Akka”, “Reactor” follow these patterns. This model puts the consumer in the front seat and hence the consumer decides the pace at which the event/message will be processed. Also, instead of the consumer polling for new updates, this model relies on push based mechanism, where the consumer/subscriber is notified using a call back function.

Pros:

The consumer need not poll for updates

The consumer can process the message at its own pace

The consumer need not wait for all the messages to be pushed before it can start processing

Cons:

Not all systems are built for reactive applications. Integration with legacy systems might be a challenge

The consumers should be build to process the continuous stream of events. Ex: Web sockets in case of browser,