DRY Principle

-
When building a large software, you will get overwhelmed by the overall complexity. Managing this complexity is very difficult without proper planning. You as a developer will then decide to conquer this complexity by dividing it in to smaller components. A Component in this system can have its own subsystem, which can be built on top of other small individual components. A component can be a class (if the software is being built in object oriented programming language) which will have a single responsibility. When you divide your system in to components and components into subcomponents, you will have a system where complexity is reduced to the web of individual components, where each component is responsible to handle a single responsibility and can focus on a specific area of a software. Any modification in such kind of a software does not require a change in other logically unrelated components. The DRY principle tells us, to not repeat these responsibilities anywhere else in the system.  
In Their book “The Pragmatic Programmer”, “Andy Hunt” and “Dave Thomas” stated DRY principle as

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"

This principle is broadly applicable to not only the code but also, Database Schema, Test Plans, the build system and even documentation.

Suppose that you are building a Book library management system, and it has a component which manages all the operations related to the Users of a system (Let’s call it UserService), like Authenticating the user, Getting the user details, keeping track of user logons etc. according to the DRY principle anything related to the user should not be repeated anywhere in the system but in the UserService or its subsystem. Any changes made to this component does not require changes to other areas of the system. it is very easy maintain such system. Understanding such system becomes very easy as every component in the system is focusing on a specific problem. Developers can alter any part of the system without worrying to much about other area of a system.

Achieving the DRY principle
Duplication can take many forms, duplication of code, duplication of logic, duplication of certain process etc. Many design patterns have the explicit goal of reducing or eliminating the duplication of logic from the system. If an object requires certain things to happen before its creation, we can user the “Abstract factory design pattern”. If an object changes its behavior depending upon the context in which it is executing we can go for “Strategy design pattern”. If there are certain process which is repeated among the objects then we can take help of the “Builder design pattern”. In fact, many design patterns are aimed to resolve the issue of duplication.

Achieving DRY is hard
In real world application achieving 100% DRY principle is hard but not impossible. It requires proper planning, discipline and more importantly it should be followed by every developer in the team, It’s a cultural thing. In Forced deadlines you would see developers writing duplicate and hacky code all over the system, which if not refactored in time, results in a bloatware system. In my opinion the many other principles rely on DRY principle which Aims to Reduce or remove all the duplication from the System. The opposite of DRY is WET which is commonly known as “write everything twice “, “we enjoy typing” or “waste everyone’s time”.  Also make sure you don’t over DRY your system, it is equally bad.

"The difference between stupidity and genius is that genius has its limit."
- Albert Einstein.

If Every developer in the team decides to follow this principle then it is not impossible to achieve a 100% DRY system.

Comments

Post a Comment

Popular posts from this blog

Threading in .Net – Part I – The Basics.

-
Image
The Problems with Single Threaded Systems In early days of computers the entire operating system was executed on a single thread. The problem with these kind of systems back then was the long running tasks would prevent the execution of other tasks causing the other applications and OS to stop responding, And if the long running task has some bug in it, or if it goes to an infinite loop then the end user has no choice but to reset the system. This was a common problem for the 16-bit systems, as they were able to access only 1MB of memory. Microsoft knew that 16-bit Windows would not be a good enough operating system to keep Microsoft relevant in the industry, so they created a new OS to address the needs of Corporations and individual. Microsoft designed the new OS (Windows NT), they decided to run each instance of an application in its own Process. A Process is nothing but a collection of resources that is used by a single instance of an application. Each Process in windows has g...
Read more

Writing High Quality Functions

-
Image
Ever wonder how to write clean functions/methods? While searching for the answer you might have come across some metrics, stating your function should not be more than 25 lines of codes or it should not have more than 5 arguments passed to it etc. When it comes to quality, unfortunately such metric are bad indicator to measure the quality of the function. It will just trigger a flag that there is an issue, but it will not tell what the issue is. When writing a high quality function, the first and primary rule is functions should be small, it should only do one thing. Sounds like Single Responsibility Principle? (SRP) yes it is, you can apply SRP not only to class, but to functions as well and this is the only measure you can use to check if the function you have written is of high quality.  FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.                               ...
Read more
-
Image
Domain Driven Design A good code base creates value for the organization and to the client. The better the code reflects the problem domain the more Money it is going to create for the organization. In his book (Domain-Driven Design: Tackling Complexity in the Heart of Software), Eric Evans first introduced the Philosophy of the Domain Driven design (DDD). While the full explanation would take a couple of 500-page books, the essence of DDD is profoundly simple: capture the domain model in domain terms, embed the model in the code, and protect it from corruption. Although let me warn you DDD is not A Silver bullet for every problem It is not the new Shiny/Trendy design pattern it is not a new template in the latest and greatest IDE’s And certainly not some coding standard/guidelines for the rookie software developers. Why one should explore and apply DDD practices? It always feels good when you look at the code which is written by you sometime back, and you are still able...
Read more