Programming Best Practices: The Art of Building Modular Applications

To build a modular application, developers a certain level of expertise. Without the knowledge of Best Programming Practices, it becomes hard and sometimes confusing to start with the architecture development process.

Many young programmers face the problem in identifying different modules of the application. And this is normal. They have not built enterprise level applications before.

But, it is not hard at all.

Yes, it’s true.

Do You Need 10 Years of Industry Experience Before Architecting a Solution?

If you are a fresher then it would be hard to convince your project manager into believing that YOU CAN DO IT.

The reason is: “You are new and yet to prove your technical expertise. And your manager would not want to bet the reputation of the company on your shoulders”.

So, just to be honest, if you are an employee of a small or mid-size company then there is a sleek possibility of you getting a chance to design the entire application from scratch. Even though you are more talented than someone with 10-15 years experience.

But hey! don’t be disheartened.

Everything is possible in today’s internet era. Knowledge is in the cloud 😉

But, keeping the company matters aside, do you really need that much experience before designing the application?

Hell No!!!

Infact, application design is the first thing that we learn in college. And if you call yourself a computer science engineer then this is a basic requirement.

You do not need 10-15 years of industry experience before designing enterprise level application. Mark Zuckerberg was just a college student when he built the biggest social network from his dorm room. And believe me he was not a prodigy. He was very much like you and me.

So, what is the missing part of the puzzle that he was able to do it and you find it difficult?

Well, this article is going to be your little guide to building enterprise level applications. You will learn how to architect your application’s different modules and encapsulate one module from another in the best way possible.

Identifying Different Modules of Your Application

A similar question was asked of Tom Wheeler, and following is his response that could be applied to any modular system:

There’s really no right answer for knowing how to split your application into multiple modules. In general, it’s better to have lots of small modules instead of a few big ones. In general, I definitely prefer to have lots of little modules than a few big ones. If you’re designing a new app from scratch, it’s easy to achieve “smallness” in your modules and you’ll have a better design (less coupling) because of it. If you’re porting an existing application to the NetBeans platform, then you’ll probably just have one or two big modules at first and you’ll have to achieve smallness as you make things more modular over time.

One rule of thumb is that you can often split the application into modules based on package boundaries. Thus, if you have the following packages:

 com.tomwheeler.app.gui
 com.tomwheeler.app.data
 com.tomwheeler.app.logic

You might refactor this into a GUI module, a data module and a logic module. As you continue development, you might find that these could be split even further. For example, your data module might have objects representing customer data and product data, so you could create a customer data module and a product data module.

Making your application modular actually makes refactoring easier because it’s clear exactly what you’ve exposed as a public API. For any given feature, I almost always strive to separate API, implementation and client code into separate modules. This allows me to develop iteratively — I can first concentrate on the API, then write a very basic implementation of it. I can then develop additional (or better) implementations of that API as time allows.

One example might be a reporting subsystem for an application. I could create an API that defines what’s needed to generate a report, but the API won’t focus on details like file format. I can then create the simplest possible implementation of that API; it might create a plain text version of the report. I can later create a new module which creates a better report, perhaps in Excel or PDF format. While I could simply replace the first version, I could also easily add a little code to let the user select the desired report format.

In addition to reducing coupling in your application’s design, having smaller modules gives you more flexibility. When your application is modular, it’s very easy to build different versions of the application with different sets of features, kind of like the “basic”, “standard” and “enterprise” versions of software you sometimes see. Doing that with a monolithic application is usually pretty difficult.

Tom? Wheeler Statement on splitting the Modules of an application

The statement is pretty clear and precise. You should write modular code. And to write modular code, you need to encapsulate everything and expose only the methods through which a consumer may interact with your module.

The perfect example and use of modular coding can be seen at Data Access Layer.

The JAVA JDBC API exposes the same methods irrespective of the data source. You can use the same code to connect and fetch data from MySQL database or Oracle or DB2 etc.

You do not have to write different code to access data from two different databases, but, in reality, the implementation of that method varies for two different databases.

In short, you only use the API methods provided by JDBC library to fetch data from the database. And you just have to provide the implementation through the connection class. Those implementations could vary from database to database.

For the database, you use MySQL driver.

For oracle database, you have to use oracle driver and so on.

Below is connection class code for oracle:

try{  
//step1 load the driver class  
Class.forName("oracle.jdbc.driver.OracleDriver");  
  
//step2 create  the connection object  
Connection con  = DriverManager.getConnection(  
"jdbc:oracle:thin:@localhost:1521:xe","system","oracle");  
  
//step3 create the statement object  
Statement stmt=con.createStatement();  
  
//step4 execute query  
ResultSet rs=stmt.executeQuery("select * from emp");  
while(rs.next())  
System.out.println(rs.getInt(1)+"  "+rs.getString(2)+"  "+rs.getString(3));  
  
//step5 close the connection object  
con.close();  
  
}

Below is the connection class code for MySQL,

try{  
//step1 load the driver class  
Class.forName("com.mysql.jdbc.Driver");  
  
//step2 create  the connection object  
Connection con  = DriverManager.getConnection(  
"jdbc:mysql://localhost:3306/dbname","root","root");  
  
//step3 create the statement object  
Statement stmt=con.createStatement();  
  
//step4 execute query  
ResultSet rs=stmt.executeQuery("select * from emp");  
while(rs.next())  
System.out.println(rs.getInt(1)+"  "+rs.getString(2)+"  "+rs.getString(3));  
  
//step5 close the connection object  
con.close();  
  
}

Do you see the difference in code?

Yes, only Step 1 and Step 2 differs. Rest everything remains the same. That has only become possible because the code is modular.

So, JDBC here is the API, that defines how a client may interact with the database. Which Database, What Database has nothing to do with it. That is an implementation part. That depends on the developer of the application.

If the developer wants to use MySQL database instead of Oracle. Then he could simply provide the MySQL driver from the connection class and rest will be taken care automatically. That is a perfect example of database modularity.

Is it Limited to their Drivers and Softwares?

Nope.

Recently, I used JDBC Library to write the implementation to retrieve data from the BigQuery Server. Although the implementation is not full-fledged, it definitely serves the purpose.? It uses the same set of methods to fetch data from the database that are provided in the JDBC API.

What is the benefit?

Well, now I do not have to teach a whole new library to the developers.? They can use the same old JDBC library which they have been using for years and retrieve the data from the database in the same ResultSet they are familiar with.

How to Modularize Your Application

Okay, first things first. As a developer, you must be aware of the three most widely known design principles of programming. That is:

• KISS (Keep It Simple Stupid)
• YAGNI (You Aren’t Gonna Need It)
• DRY (Do not Repeat Yourself)

Let’s take each design principle one by one.

Keep It Simple Stupid!

I would like to quote the definition of KISS Principle from the pages of itself:

The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided

Source: Wikipedia

I love this principle personally. I mean why to make things complicated if they could be really simple and easy (Maybe to impress your manager :p).

The way to look at the problems holds the key spot here. I have seen developers complicated a simple task in a way you can never imagine.

Let’s take a very simple example to understand a very big situation:

private static int sumList(ArrayList<Integer> list)
    {
        int sum = 0;
 
        for (Iterator<Integer> iter = list.iterator(); iter.hasNext();)
        {
            sum += iter.next();
        }
 
        return sum;
    }

The above code can be simplified to this:

for (int x : list)
    sum += x;

This is very simple example of how you can make your code concise and precise by eliminating all the non-required elements (parenthesis, variables etc.). But people mess up. Even experienced programmers mess it up.

Similarly, while designing your application, you must not think of all the stuff at once. You must take individual module at hand and try to excel that modules to its finest.

I have seen senior programmers explaining so much about the architecture before even realizing the exact requirements (I actually make fun of them secretly :p). I have heard them talk about the database abstraction, service abstraction, Business Login layer blah blah blah…

For God’s Sake. You cannot start with the abstraction. Can you?

‘Abstraction’ is a dirty word.

However, some programmers shout ‘abstraction’ from the rooftops and peddle it as a salve to all programming woes and I get all fidgety.

It’s not like I’m against abstraction or something of that sorts. It’s just that, ‘abstraction’ has become a buzzword in the field of computer programming and architecture design. Every developer wants to use the word ‘abstraction’ just because he thinks it makes him sound wise.

The truth is: if you are talking to someone who actually knows about abstraction then you have just made yourself sound like the stupidest person on the floor.

Abstractions are used to create a layer of separation between different module so that the module can be replaced in the future as required without affecting the existing code. You cannot abstract modules which are yet to be built :/

Try to understand from the following perspective: If you have to build a car. It has different parts, an engine, gear, clutch, accelerator, wheels etc. How are you going to think about it?

Will you be thinking about the abstraction worrying about “what if I have to change my Ferrari’s engine with the Lamborghini’s in the future without changing the chamber that holds the engine” especially when you do not have an engine in the first place. I hope you get what I mean.

Similarly, you cannot abstract different modules from each other before you actually have built it in the first place.

Making your application modular is not abstraction. It is segregation. And segregation is always good but abstraction is subjective.?

I would like to quote the lines from Pete Smith blog:

If you think you’re writing software that will survive, unchanged and perfectly functional for decades, you’re probably wrong and I’m sorry.

If you do work on that project, then you are likely to make some poor programmer’s life a living hell as he’ll be booting up Windows XP or Internet Explorer 9 in 2030.

Source: Abstraction is Dirty

So, will you start with the abstraction or will you start with the actual code The Choice is yours.

Take my advice – Keep It Simple and start from the requirement phase. You will thank me later. And remember:

You Aren’t Gonna Need It

YAGNI is a principle that comes straight from the books of Extreme Programming. It states the clear and specific requirements of the project and expects nothing else. No future requirements, no broadening of the specification and no extra work. Just do what is required to be done and that’s all.

To understand more closely, let’s say you are working on a pricing system to add support from risk from natural disasters. Now, there is another part of the module that deals with the pricing for piracy support. Since you are working on the pricing engine, you started considering the presumptive feature of piracy pricing support.

YAGNI is strictly against this. It says, if you are not needing piracy pricing support for the next six months, then you should not consider it with the existing iteration. Instead, if you think you have extra buffer time, use that time to further optimize the existing feature.

So, what’s the big deal?

Time.

Developer’s time is money. To build that extra feature, it will require more analysis, requirement gathering, coding, unit testing and a lot more. And who knows that feature might not be needed in the future.? Hence all the efforts made will be soiled. Plus it will cost you a lot.

To understand more about the YAGNI principle and its implementation, read Martin Fowler’s article:

• YAGNI – By Martin Fowler

Do not Repeat Yourself

Perhaps the most important part of a programmer’s code. You should write code in such a way that you do not have to write it again for a similar functionality.

This is not an easy task as it sounds like. Working in a multiple developer environment is a challenge in itself. You would never know if a functionality has already been implemented by a programmer already.

I have faced this thing in my experience. And in the act, I wrote more than 1000 lines of code to achieve a functionality that was already there. Since then I made a habit to ask the fellow programmer before implementing some common functionality to the code.

Also, I have developed a habit of writing code once and if that code seems to be used in more than one place, I take that code out and put it in some utilpackage or a place where it could be used by everyone. This tremendously reduces code maintainability aspect and developer’s time that would be spent on implementing logic and writing code for it.

How to Split Application Into Different Modules?

Stop thinking in the terms of Modules. Start thinking in terms of features.

Take the requirement, built a simple approach and start.

Once you start building application, your code base grows. Your utility methods and classes starts to develop. And now you start seeing the common patterns.

For example:

Take a simple example of fetching the user’s information from the database and performing some logic on the data and giving it back to the consumer.

In this case, you will first start with the basic requirement.

The requirement is to provide the consumer with the information he asks for.

Now suppose the consumer wants to know the personal information of all the employees in the database. To this requirement you need to ask following questions:

• How can a consumer communicate with your application?
• Where you can find the required data?
• How can you obtain the required data?

To fulfill each requirement, you start developing solution. So for the above question, you might come up with below solutions:

• Provide an Interface from where a consumer can communicate. It could be a GUI or a simple API.
• Your data could be retrieved by consuming another service or from a database. Write appropriate code to get the information.
• Develop a Business Logic to retrieve the required data.

You will see that your code base will start to grow with every new requirement. This is the time when you need to sit back for a minute and start segregating the application into different modules based on the work they do.

The above steps will grow to become three different modules in your application:

• A View/Gateway through which he can interact with your application and ask for the data.
• A Data Access Layer that would fetch the information from the database.
• A Business Layer that would perform the operations on the data to achieve the end result.

Do you see how things can be divided into different modules and made more manageable?

If yes then leave a comment below about the overall experience of this article. And if no then comment below the? things that needs to be talked more. I’m open to your suggestions.

Conclusion

Modules are not the building blocks of your application. Infact, a monolithic design was the basis of all the computer programming we see today.

Modules are just a human way of making things simple and more manageable.

Once you understand the need of modularization and you actually starts creating it. It is that simple.

Creating modules just for the sake of creating it is not a wise approach towards programming. Different people might have different thoughts, but I like to keep things simple.

If you code base is small and could be managed easily then there is no point in creating a separate module just for the sake of keeping the business logic in separate space. But if your code base have grown to tens of classes then it is only wise to create a separate module and segregate your project.

Need is the mother of all invention.

If it is not required, don’t do it.

Let me know your views on modularizing the application?

If you truly loved the article then help us by telling it to the world.  Share this article in your circle.