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

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.

<menubar>
    <menu>
        <index>1</index>
        <name>File</name>
            <item>
                <index>1</index>
                <name>New</name>
            <item>
            <item>
                <index>2</index>
                <name>Save</name>
            <item>
            .....
            .....
    </menu>
    <menu>
        <index>2</index>
        <name>Edit</name>
            <item>
                <index>1</index>
                <name>Cut</name>
            <item>
            <item>
                <index>2</index>
                <name>Copy</name>
            <item>
            .....
            .....
    </menu>

</menubar>

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