I am Siva, a passionate java developer, open source enthusiast, blogger. I like to cover Java, Struts, Spring, Hibernate, Ajax Tutorials, How-To's and Best Practices. Sivaprasadreddy is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

The Next Level of the Don't Repeat Yourself(DRY) Principle

  • submit to reddit

We have been building software applications using various languages for several years. Over this time new frameworks, new tools, new methodologies have appeared. Especially in the Java platform, where we have plenty of choices in each area following various design patterns and principles like MVC, FrontController etc.

We have many development principles like KISS(Keep It Simple Stupid), DRY(Don't Repeat Yourself) which encourage developers to write better, more maintainable code. The DRY principle in particular, is a very good one which every developer should understand and follow.

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

So the DRY principle is saying that if you need to write same piece of code in many places, instead of copy-pasting it, make it as a seperate method and call that method whereever it is required. This is applying DRY at the code level.

I really appreciate the Jakartha-Commons Utils authors for practically implementing DRY principle. Whenever I need a utility like some String operation, Date calculation, Regular expression, property loading etc I just open the Jakartha-Commons website and I am sure I can find what I need there.

Even though each application has its own set of business requirements there are many things which are common to web/enterprise applications. Especially infrastructure code which may be similar to many applications.

Now I think it is time to take DRY priciple to the next level, I mean to apply at functional level.

Let us see where we can apply DRY at functional level. The following are some of the things where we can build reusable components/small projects which we can directly use with other projects.

1. An application multi-level menu bar:
I have seen many applications having a horizontal menu bar at the top of the page with single/multi level sub-menus. The menu bar can be built using Javascript or custom tags. What I am suggesting is if we can build a CustomTag to generate a Menu bar from an xml configuration and a style sheet that the component can use in any project.

For Example:

We can create an xml structure for our menu as follows and create a custom tag to parse that xml and render a menu bar with a default stylesheet. If the user has provided a custom stylesheet, the custom tag will use that.



2. Role-based authentication and authorisation system:
I have been involved in many projects where the application users will have one or more roles and each role has one or more privileges. Each privilege is nothing but an action that a user will invoke in the appliation. Application events will driven by role based authorization. And also there could be a requirement to create user groups and assign privileges to user groups instead of individual users.

I think this Role based Authorization System can also be built as a component which we can plug in to any project.

3. Job Scheduling:
For many enterprises there could be several batch jobs that should be run on particular schedules. I think there is a need to build a job scheduling web application with the following features:
    a) A web based UI to create and schedule new jobs
    b) Provision to track the status of the running jobs
    c) Provision to run jobs in adhoc manner
    d) Provision to reschedule, terminate a job
    e) Informing the concerned groups about the status of jobs through emails
    f) Automatic email notifications on job failures

We can build a web application with the above mentioned features and leaving business logic implementation in the jobs for the developers.

4. Sophisticated logging system:
While developing the application logging plays a vital role in debugging the problems. We can use AOP for logging in a better way with cleaner approach. Many times the developer needs to check what parameters are being sent to methods and where it is throwing an exception.

For this we can write MethodParamsDumperAspect using SpringAOP+AspectJ which will display the method parameter values using reflection/commons-beanutils. The only thing which a developer need configure is the base package name.

5. Configurable and customizable workflow engine:
I have seen many intranet portals with HelpDesk applications with the following features.

1. A customer will raise a request.
2. The system will identify the workflow to process the request and the request will be routed to the concerned person.
3. The requester can view the status of his request as each step is in progress.

Like this there are many WorkFlow based systems. We can build a generic workflow engine where in the administrator can setup the metadata like Request Types, Steps for each request, Request Status codes etc.

So here my point is all these days we followed DRY in writing code. Let us take it to the next level in building components/sub-projects.If an architect or developer got a requirement to build a reusable component, it would be great if he/she can publish his/her approach (and code if possible) so that the other developers across the Java community can use the approach/code instead of reinventing the wheel.

From : http://sivalabs.blogspot.com/2011/01/next-level-of-dont-repeat-yourselfdry.html
Published at DZone with permission of Sivaprasadreddy Katamreddy, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Aaron Digulla replied on Wed, 2011/02/09 - 6:36am

 Most of those already exist.

 For role-based authentication and authorization, look at Spring Security (http://static.springsource.org/spring-security/site/)

 For job scheduling, look at Quartz (http://www.quartz-scheduler.org/)

Logging is fixed by slf4j (http://www.slf4j.org/) with logback (http://logback.qos.ch/) and your preferred approach to taint the sources with it (AOP or text editor)

For workflows, I have no preference, yet but you can have a look at all the goodies on http://java-source.net/open-source/workflow-engines


Sivaprasadreddy... replied on Mon, 2011/02/14 - 12:13am in response to: Aaron Digulla


All the stuff which you mentioned are standalone APIs for their respective tasks.

Take Quartz, using quartz we can write the job scheduling applications. I agree.

But my point is we should have a framework kind of semi completed job scheduling application which can be used by anyone by plugging-in their job implementations. And the framework should take care of rest of the activities that I mentioned in the above post.

Similarly for Logging, If we can write an Aspect to print the method parameters in details in such a way that anyone can use that aspect and be able to print method parameters in DEBUG mode by just passing their pointcut details.

 Your thoughts??

Thomas Kern replied on Thu, 2012/09/06 - 10:48am

If there are already exists those reusable components i will be more than happy to use them. If you can point me to some url's of those reusable components that would be helpful.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.