Software development is an art to me. To develop an application to get the current job done may not pose a challenge. However, if you want to develop an application that can be easily extended for the future requirements, you may need to give it a thought before coding. This article is not going to teach you OO design b/c you will find it from many good books. It is also not teaching you design pattern b/c you are not presenting a problem to solve here. What this article tells you is some design guidelines that I have learnt so far from reviewing the architectural work of some successful open source solutions like Quartz and Struts. My goal is to help you to develop an application that can embrace changes and gradually grow itself to become something solid and mature to ship. Many good design methodologies today are to help you to do one thing - minimize the code change. When your application grows in size and complexity, you want to manage its complexity because you don’t want your development time proportionally increases with it. To manage complexity, there are practices you may learn in old days like:

1. Encapsulation - like you use the car braking system without necessary knowing the detail how it functions.
2. Increase cohesion and decrease coupling - so you can easily spot the piece of the code that need to change and minimize the ripple effect during code change via reducing inter-component dependency. This is the driving force for component design behind the scene.
3. Apply design patterns - with patterns you make your code easily to understand for someone who knows design patterns. That will dramatically improve communication and code clarity. The key is you don’t need to re-invent the wheel to solve the solved problem.
4. Code against interface - make the implementation details hidden and replaceable. Unit testing will become easier. With the advent of IoC, you can inject the concrete implementation during runtime. So, you don’t need to do any code change to replace implementation.

These are golden rules that I have followed and proved working. Below are some of the guidelines that I have noticed in this industry after years of evolution around these concepts.

1. Look at the volatile part of your code and externalize it (eg. xml) - like workflow BPEL.
2. AOP to factor out the cross-cutting concerns from the code like security, logging, transaction management. This will help you to focus on the business logic and put your system in higher consistency. This concept is further enchanced by Annotation.
3. IoC for object creation and lifecycle management.
4. Put extenstion points into your system - listener and plugin API. Listener is used to register notification points during state change of a subject. For example, you will see people put listener for session creation and destroy. Plugin is to extend the capability of the system without modifying the existing code.
5. Wire up components in declarative fashion via meta language like Pentaho action sequence in reporting.

Those are the guidelines I have found so far. Suggest me some more to make it completed.

 Reference

http://www.onjava.com/pub/a/onjava/2004/11/10/ExtendingStruts.html