Breaking the Rules Part II: Stop the Method Madness

Break the Rule: Implement business logic in methods or operations.

From the beginning, developers implement logic in methods. This is fundamental to programming because you need to execute code and logic. I’m not saying that we cannot use methods or operations in our code – this would be impossible. However, we need to stop putting valuable business logic in methods.

When we do this our application logic becomes a method calling a method, calling another method and so on. The logic is a chain of methods executing to create the desired behavior. There may be certain scenarios where using this approach is acceptable. However, the context that we are concerned about is implementing business logic.

Using single methods or method-chains is difficult or at times impossible to test. You cannot isolate the specified unit to test because there are dependencies in the other methods called. Therefore, since it so difficult to unit test – you probably do not create unit tests. Not unit testing is like going on a road trip without car insurance, road-side assistance, or even checking the dashboard to determine if you have enough fuel for the trip. I have seen people approach software without the securities of unit tests. But I do not see many people driving across the desert with extremely bald tires. Again, why do we take precautions in real-life when things matter, but do not take any when developing a software solution that costs thousands and sometimes millions of dollars.

Adding new behavior becomes more difficult in method-based business logic. You will start to see and smell the “if, then” clauses scattered throughout the methods. In the beginning of a software project, the difficulties of this approach are not as evident. Yes, there are few “if, thens”, but everything seems to be working fine. They become a dark chaotic reality later in the project. This is when discussions start about re-writing the application and doing it right this time. When in reality there wasn’t anything stopping you from doing it right from the beginning.

Treat business logic like first-class citizens in your application. Do not use methods. Implement them in classes so that you can benefit from object oriented features. You get object inheritance and sharing of common behaviors in base classes. You also get more extensibility opportunities using a class approach. Another benefit, is that your classes are easier to unit test.

The Vergosity Framework allows you to use this class-driven approach to implementing business logic. You can create your own framework – it is easy to do using a simple design pattern called Template Method.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s