DEV Community: Dibyojyoti Sanyal

How to avoid God Class in OO Programming ?

Dibyojyoti Sanyal — Sun, 05 Sep 2021 10:16:35 +0000

When we learn programming we tend to put all the code in the same function or even in the same file. Especially in the functional programming paradigm, for example in C, where the program logic is driven by sequence of method calls and execution logic rather than communication between objects. Object oriented programming supports communication driven program execution among representations of real world objects. In functional programming as the starting point is the main method we tend to write the whole program in the same method. Sometimes we factor out the logic in separate methods which are called sequentially from the main method. At best we create separate files that contain few methods, this file can be reused. In Object oriented programming everything revolves around a few objects where one of the classes contains the main method and acts as the entry point. Object Oriented design principles suggest that there should not be one single God class. Today we will discuss what that exactly means and how to avoid creating God class.

What is a God Class or a God Object?

A God class is a class that tends to have every solution possible logic. Rather than provisioning a solution to a specific problem a God Glass tends to have different kinds of code logic that solve different problems. When we can call different methods on the same object to perform different tasks we can say the object is doing too much and it's a God object. Wikipedia has a good explanation on the God object.

Why do we need to avoid God Class and God Object ?

There are many problems that are associated with God classes and God objects. Few of them I have mentioned here:

The size of code with a class increases and makes it unnecessarily complex.
God Class and God objects creates tight coupling between unrelated code which becomes difficult to enhance and maintain in future.
The single responsibility principle in object oriented design principles says one class should only do one thing. This principle is not followed in God classes and God objects.
As these classes and objects do many tasks they lack modularization concept which hinders code reusability.
Different independent code logics are intertwined in God classes and God objects. For this reason, testing of each functionality separately becomes difficult.

How to detect God Class ?

I have listed a few tips that will help you detect God Class and God Object.

Like the main method in C which is the entry point and central component that manages the whole working and dataflow, when you find similar classes or methods you can smell God Class.
Generally Gog Classes have a large number of code lines.
A class that performs several tasks to solve different not related or less related problems are candidates for God Class. Generally these classes offer a lot of functionality which are not related.
When a class has many unrelated properties and exposes methods to manipulate or fetch those properties, this class becomes a God Class.

How to refactor a God class ?

A systematic approach will let you identify, plan and get rid of the God classes and God objects.

The first step is to identify the God classes and objects in each package and module.
Next, we need to identify the clients of the God classes and objects who use these classes and objects. It will help us to assess the impact of the change we are going to perform.
Then we need to come up with a new low level design to remove God classes and objects. In the design we need to take care of these below points.
- For the static methods a separate utility class needs to be created because an object is not needed to invoke the static methods.
- Similarly the static and final variables can be separated out.
- Group common methods and properties following single responsibility principle. Create separate classes for each group.
- Use inheritance, association and aggregation to establish a clear relationship among the classes.
- Use high cohesion and low coupling principles.
Factor out the less frequently used part first and then work on refactoring other parts.
Create unit tests to test the new code thoroughly.

How to avoid creating a God class ?

There should not be one single class that does all. Instead there should be a bunch of classes which are needed to perform some tasks in a certain sequence, and will be used at different points of time in the sequence. In certain scenarios it makes sense that, once the work of a class is completed it can be garbage destroyed or collected. To avoid one class performing more than one task, before creating a class create an interface and define the methods the interface will contain. Carefully, look at the interface methods to judge whether the methods solve only one task and the contract as a whole provides one functionality. Once you are sure, implement the interface in a class.

You can refer to my blog post for example of God classes and solution of how we can avoid creating God classes.

What design & build incrementally means in OO design Principle ?

Dibyojyoti Sanyal — Sun, 05 Sep 2021 09:50:22 +0000

This is one of the Object Oriented Design Principles that helps developers keep the code readable and understandable.

When you try to make the whole design and start implementation that will not work because either you will find your previous assumptions were incorrect or the requirement changed. Therefore, it is better to design in a way that the design can be extended and the same basic design building blocks can be reused in other parts of the code. While designing we also need to adhere to homogeneity, which means similar things should be designed and implemented in a similar way and orientation of similar parts of code should look like the same. This is how we can design and build incrementally, once small pieces at a time.

Example, when you need to implement an HTTP connection and a JDBC connection to a database. The actual code will be very different but you should design it in a way that the same design patterns can be used in both places, the high level method names and the class hierarchy and relation between objects should be similar in both implementations. Though implementation details and the objects itself will be different but the interaction and responsibilities divided in different classes and methods in high level should look similar. It makes the code easy to understand also, as human nature is such that it recognizes the known patterns easily.

You can refer to my blog post for a concreate example.

How to apply transparency in OO programming ?

Dibyojyoti Sanyal — Tue, 31 Aug 2021 18:40:06 +0000

Transparency is one of the Object Oriented Design Principles that helps developers keep the code readable and understandable.

When you look at the class or methods it should be very obvious immediately what it does, within the next 1 minute it should be obvious how it does what it does. You as a programmer should be able to understand the piece of code that you have written after several months even years when you look at it. Moreover, others too, should take the same amount of time that you took after 6 years to understand the code that you have written. For Example, when anyone looks at the name of a class and its member variables and methods they should understand what they do and how, without any effort.

The name of the class should explain what it does or what it stands for.
The name of the variable should say what it is used for.
The name of a method should explain the action that is performed when the method is called.
A method name should have a verb to make that happen.
The same goes for the name of the objects, they should say what they are used for and in which context.
Normally a class is named as a noun example Employee class.

As an example, an Employee class can have variables, to maintain the state of an employee object. When the task of the Employee class is to keep age, salary, name, department details of an employee then the variable names should be like age, salary, name, department. We should use the easiest name that identifies what the variables are for.

Here is another example for the methods. When a method increments the salary of an employee then name it like incrementSalary(). You can increment salary by providing an increment percentage or an adding a float amount to the existing salary. Then name them differently like

incrementSalaryByPercentage(double percentage)
incrementSalaryByAmount(long additionalAmount)

Now assume a department consists of 5 employees. and one of them is an IT manager, another is an accountant, another human resource manager and two programmers. You will create 5 objects of the same Employee class in the Department class. but name the name of each Employee object should explain their role like ITManager etc.

When you start creating classes, start from top to bottom. That means write the user interfaces first to provide transparency. Things like services, databases etc. should be at the bottom of the structure and written later. It should be done this way so that, even if there are changes in the technical layer like how to access the database it should not affect the upper layer.

This way just by following a good naming convention we can make our code easy to understand and transparent.

For the original post please refer to my blog
You can see similar posts in Object Oriented Design here

What simplicity means in OO design principles ?

Dibyojyoti Sanyal — Mon, 30 Aug 2021 19:46:15 +0000

Simplicity is one of the Object Oriented Design Principles that helps developers keep the complexity low in an object oriented program.

Do not code for future

It says, a class and its method should be as simple as possible, the code should do exactly what it should do, nothing more. We should refrain from anticipating some functionality for future and implement it for completeness. It's better to code what is known as of now and code in a way that it can be easily extended when new functionality is needed.

Do not provide many arguments

Sometimes programmers add more arguments to methods to make it more generic so that it can handle a lot of cases. But in reality all parts of the code may not be executed because all the possible scenarios the programmer thought of, is not happening now. just write what is known to be happening and don't make your method a generic one.

Detect reusable logic and refactor

If you anticipate you are writing a logic part of which can be used later in some other cases, break that method into parts, white the reusable logic in separate method(s). Call the reusable method from another method.
An easy way to detect this is, when during development you need to refactor a certain part once that means it might have to be modified later too. So better to put an extra effort to refactor it so that later a refactoring is not needed, otherwise just leave as it is. You can use design patterns to refactor the code and write a more general solution but design patterns do come with more code and complexity. So if the situation demands it then only apply it.

To read the main blog post with a concrete example please refer this link
To read all my posts related to Object Oriented Design please refer this link

What are the characteristics of Object Oriented Design Principles ?

Dibyojyoti Sanyal — Sun, 29 Aug 2021 08:09:01 +0000

Object Oriented Design principles

Object Oriented Design principles help users to write high quality code. Today we will see what are the characteristics or what the design principles give when they are followed. To understand OO design principles you should know at least one OO programming. Here I have chosen to use JAVA. There are several principles and several names of the same principles. Here I will list the most popular basic ones which are well received and well known. I will list here what the characteristics are.

Transparency
Simplicity
Incremental development approach
Cohesion or Coherence and Coupling
Orthogonality

To read an explanation on each of the above five points you can refer to my blog post

What is Object Oriented Design(OOD)? Why use Object Oriented Design(OOD) Principles ?

Dibyojyoti Sanyal — Sun, 29 Aug 2021 07:55:37 +0000

What is Object Oriented Design(OOD)?

Object Oriented Design teaches us some basic design principles to write high quality Object Oriented programs. The principles are learned from the common mistakes done by developers. The principles are the guidelines for the developers to avoid the same common mistakes.

Object Oriented Design(OOD) Patterns vs Principles

People might have heard about Design patterns and think we are going to talk about design patterns here. Design patterns provide few well known best practices to be used for some well known circumstances/scenarios and tells about how different classes can be written and used together in each scenario.

Object Oriented Design is more about basic principles, building blocks which programmers should keep in mind when they write programs. The Object Oriented Design principles can be applied in each design pattern, and in turn design patterns obeys the OO Design principles. That means they both are complementary and work together to handle different scenarios.

Why use Object Oriented Design Principles?

Any developers who write programs using any object oriented programming language should keep in mind the design principles and examine the code after writing whether the code is aligned with the design principles. The reasons why we should do this is because the code base becomes:

Easy to maintain(maintainability)
Easy to extend(extendibility)
Easy to understand(understandability)
Easy to test(testability)

Please read my blog post to for detail on above four points

Error Handling with HTTP Error Response Generation in node.js Application

Dibyojyoti Sanyal — Sat, 28 Aug 2021 11:48:28 +0000

In one of my blog posts Separate routing from business logic in node.js | Central response generation in node.js we have seen how we can perform central HTTP response generation from the responses generated by the business logic module. In application different error conditions can occur. We would like to code for those error conditions using a try-catch, and throw constructs provided by the programming language. But that is not good when it comes to HTTP error responses. In cloud native application development we need to convert those errors to HTTP error responses. It would be necessary to handle the throws exceptions from code and convert them to HTTP error responses centrally.
We can create a errorHandler.js file where we write the code to convert the errors to HTTP responses.
The errorHandler will look like this

function errorHandler() {
  return (err, req, res, next) => {
    if (err instanceof TypeError) {
      return res.status(400).json(err.name + ": " + err.message);
    }
    if (err && err.statusCode) {
      return res.status(err.statusCode).json(err.body);
    }
    return next(err);
  }
}

module.exports = errorHandler;

Then we need to import this errorHandler to the application server and apply it as app.use(errorHandler). In this way we don't have to convert error to HTTP response in every place, we just do it in one place. Of course, in all those files where error can occur we need to use try-catch-throw construct to throw errors. All those thrown errors will be caught by this block of code centrally.

For an complete example please refer to my blog post.

Separate routing from business logic in node.js | Central response generation in node.js

Dibyojyoti Sanyal — Fri, 27 Aug 2021 15:42:09 +0000

Its important to keep the code that executes the business logic separate from the request routing. The separation helps code modularity and enhances separation of concerns. In my post What are routes in node.js ? How routes help writing modularized code ? I explained how we can use routers to handle multiple APIs, each API family can be separated using a separate router. You can easily imagine when the actual business logic is implemented the inline-function in the routers that handles the request will be much bigger and complicated.

First, as the number of APIs increase, keeping the routing logic and the business logic to process the requests in the same file is not going to scale and becomes cumbersome. We would like to separate the business logic from the routing logic. The router layer just should contain the routing logic and the business layer contains the business logic, the routing layer should use the business layer functions. For example, when we do user management (e.g create, update, view user) and order management (create, update, view order) we write all logic related to user management in a separate .js file and logic related to order management in another .js file. Here we write the business logic that is needed for user and order management. We can also write a separate function for each operation (e.g create user, view user, update user) in each of the files. Then we create a router for each routing family, for example a router for user management that starts with /user, a route for order management that starts with /order and so on. And finally we associate the particular REST call in the router with the particular operation in the business logic. For this we just have to import the .js file that has the business logic to the .js router file. You can see an example in my blog here

Second, in each function when we perform HTTP response generation we are repeating some of the logic necessary for response formulation. We should have a central method for request processing, used by all functions for all routers. I have also shown this in the same blog that I have linked above.

Manage Node applications using PM2

Dibyojyoti Sanyal — Tue, 24 Aug 2021 19:01:20 +0000

What is PM2?

PM2 is a daemon process manager that helps micro service developers in node manage and keep applications online. Using PM2 is straightforward, it offers a simple and intuitive CLI. it is installable via NPM.

What it can do for us?

Using PM2 we can start, restart, stop, delete an node application. That means we can manage the application lifecycle of node applications using PM2. Feel free to read my blog for details with example.

How to add multiple routers in a node application without using app.use() for each router ?

Dibyojyoti Sanyal — Mon, 23 Aug 2021 16:55:17 +0000

In node.js, when we have multiple Express.Router written in a separate file to enhance modularization we need to import each route file into the application server file and add lots of app.use() statements. Now, if we add a new router we need to remember to add that too in the file where the application server is written.

Let's assume there is a routes folder where the routes are defined for user and order handling separately in separate files. in application server file we need to use app.use two times. imagine if our routers increase the solution will not be very good.

we can add a small code snippet in our application server JS file that will automatically import and add all of the routes in the application.
In this blog I gave an example of the initial approach and also showed how that code snippet looks like.

Generate human readable REST API document in NodeJs using an apidoc node module

Dibyojyoti Sanyal — Sun, 22 Aug 2021 09:27:06 +0000

Node.js is one of the top preferences of programming languages In cloud native application development. Many micro services provide functionality by exposing REST APIs. It's important for developers of consuming applications as well as the provider application to be able to read the definition and capabilities of each and every REST endpoint. The apidoc node module comes handy, this module helps application developers define and document the REST APIs with very less effort.

What is apidoc?

apidoc is a node plugin that can be installed in the node application. This plugin helps to write and generate REST API documents for node.js applications.

How to generate API documents using apidoc ?

First we need to install apidoc in the node.js project. Then we can use the @ parameters and formats as comments in the node.js files. After that we need to run a command to create the documentation. Apidoc scans all .js files in the path. It creates a nice human readable HTML static file from the comments in the .js files. The comments can be added in-place on top of each node route that provides the REST functionality.

A better approach though, is to separate the comments for documentation separate from code. We also can write all comments for all APIs in a separate .js file. Also, we can write a code snippet that will generate the documents automatically. Let’s see an example to understand it better.

The package.json file

{
  "name": "Test-App",
  "version": "1.0.0",
  "devDependencies": {
    "apidoc": "^0.25.0"
  },
  "apidoc": {
    "title": "Test-App API Documentation",
    "order": [
      "Users",
      "User"
    ]
  },
  "engines": {
    "node": "^12.18.0",
    "npm": "^6.14.4"
  }
}

In package.json we have mentioned the apidoc version under devDependencies. Note the app name and version, it will be used in the apidoc generated document. This file also has an apidoc element, here the title of the generated apidoc HTML file can be defined. The groups names and their order can also be defined here. Read along to know what groups are groups.

The .js file with apidoc comments

Here is a users.js file that contains all the comments. The file assumes creating a document for REST APIs for user management. It contains listing all users, creating and updating a user.

/**
 * @api {get} /users Get all users
 * @apiDescription Returns All user names.
 * @apiPermission None
 * @apiName GetUsers
 * @apiGroup Users
 *
 * @apiSuccess {Object[]} response Services metadata.
 * @apiSuccess {String} response.name user name.
 *
 * @apiSuccessExample {json} successful response(200 OK):
[
    {
        "name": "user name"
    }
]
 *
 * @apiError (Error 4XX) 404 Not Found.
 * @apiError (Error 5XX) 500 Internal Server Error.
 */

/**
 * @apiDefine ErrorCodes
 * @apiError (Error 4XX) 400 Bad Request.
 * @apiError (Error 4XX) 401 Unauthorized.
 * @apiError (Error 4XX) 403 Forbidden.
 * @apiError (Error 4XX) 404 Not Found.
 * @apiError (Error 5XX) 500 Internal Server Error.
 */

/**
 * @apiDefine UserRequestBody
 * @apiParam (Body/Json Parameter) {String} email Email of user.
 * @apiParam (Body/Json Parameter) {Number} age Age of user.
 * @apiParam (Body/Json Parameter) {String} name Name of user.
 * @apiParam (Body/Json Parameter) {String} [expdate] Optional membership expiry date.
 *
 * @apiParamExample {json} example request body:
 * {
 * "email":"name@gmail.com",
 * "age":"1",
 * "name": "name",
 * }
 *
 * @apiSuccess {String} msg operation successful.
*/

/**
 * @api {post} /users Create user
 * @apiDescription create an user
 * @apiPermission Admin
 * @apiName CreateUser
 * @apiGroup User
 * @apiUse UserRequestBody
 * @apiSuccessExample {json} successful response(200 OK):
 * {"Msg":"Successfully created user with email: ***** "}
 * @apiUse ErrorCodes
 */

/**
 * @api {put} /users Update User
 * @apiDescription Update an user
 * @apiPermission Admin
 * @apiName UpdateUser
 * @apiGroup User
 * @apiUse UserRequestBody
 * @apiSuccessExample {json} Success-Response(200 OK):
 * {"Msg":"Successfully updated user with id: ***** "}
 * @apiUse ErrorCodes
 * @apiError (Error 4XX, 5XX) 400 Bad request.
 */

To read on the explanation of the tags read my blog generate human readable rest api document in nodejs using an apidoc node module

Now, I have written a code that can generate the documents automatically. The file name is genAPiDoc.js and its content is given below.

const apidoc = require('apidoc');
apidoc.createDoc({
  dest: "./webapp/apidoc",
  src: ["./apidoc_source"]
});

The source means the documents in commented form will be read from the apidoc_source folder and the docs will be generated under the webapp/apidoc folder.

The folder structure of our small project to generate api documentation I have depicted here

apidoc_source
  /users.js
node_modules
webapp
  /apidoc
genAPiDoc.js
package.json

At this point we have everything to generate the HTML document. To install all NPM modules we have to run the npm install command. Then we run the node genAPiDoc.js command to generate the human readable document. You will see lots of files and folders generated under the webapp/apidoc folder. Among them you will find the index.html. This is the file where we have the output of the document in a nice human readable format.

The screen shot of the html files generated are here

For the full view of the html page see my blog post

How would you access form data without using bodyParser ?

Dibyojyoti Sanyal — Sun, 22 Aug 2021 08:13:33 +0000

Generally we use the body-parser node module to parse request bodies. When for some reason we don't want to use express or want to know how the body-parser probably works, this post explains how developers in vanilla node.js can extract request bodies from an HTTP(S) POST, PUT and PATCH request. The request object in express works with few stream events. One of the events is data and another is end. Using these two stream events we can do our job.

What are streams in node.js ?

Streams are one of the fundamental concepts in node.js used for data- handling. Using streams we can read data from an input and write data to an output in a sequence. Streams can be used in any kind of information exchange. For example, to read data from files and write data to files. Streams can be used for network communications also. In streams data is not read from input at once and then written to output. Instead data is read and written at the same time as a sequence of chunks. This makes streams powerful when dealing with large amounts of data. We can write memory and time efficient code using streams. Streams uses an asynchronous programming model and provides few events to listen to. That is a brief on streams which we need to understand for this post.

What are data and end events?

A data event is triggered when the stream receives a chunk of data. When the data ends the stream end event is called.

How to use stream events to read and parse data from a request object in node.js ?

We need to implement logic on the data and the end stream event. We have to listen to the data event and capture the chunk from there. Then we collect it in a variable. We also need to listen to the end event. When the end event is generated we are sure that we have received all data chunks sent as a request body. We need to consolidate the data we collected and process the data as a whole. Here in this example, we are verifying whether the data starts with a curly brace, if it is then we assume the data is in JSON format. So we convert it to a JSON data structure. After that by calling the next() method we finish the data processing on the hook that we have written on the end event and pass the control to other event listeners that may exist.

app.use(function(request, response, next) {
  let whole_data = '';
  request.on('data', function(data_chunk) {
 console.log('on data: ', data_chunk);
 whole_data += data_chunk;
  });
  request.on('end', function() {
 req.rawBody = whole_data;
 console.log('on end: ', whole_data);
 if (whole_data && whole_data.indexOf('{') > -1 ) {
  req.body = JSON.parse(whole_data);
 }
 next();
  });
});

The above code is just an example of what we might like to do when we get the whole data at the end. We can write any logic we want here. For example, if we just want to print the whole data, the code will be as follows.

app.use(function(request, response, next) {
  let whole_data = '';
  request.on('data', function(data_chunk) {
 whole_data += data_chunk;
  });
  request.on('end', function() {
 console.log(whole_data);
 response.end();
  });
});

You can read it in details here
To read more about similar posts see my blog