Java(TM) Boutique - Designing Abstraction

Tutorials : Designing Abstraction :

All said and done, why is it called Dependency Inversion Principle? The answer is again in thought thinking patterns. In the traditional approach, we start thinking from the high-level modules and cascade down to the lower levels. For example, we initially thought, we need an object to write data to the database and then created another object to write the data to the database and strongly coupled the high-level writer object to the low-level database writer object. This led to the bad design.

In Dependency Inversion Principle, we started thinking from the low-level modules. We identified that we may need to write to different destinations and thereby may need many Writer objects in the system. But all of them are writing data to somewhere and abstracted it to the Writer object. Then we associated this abstraction to the high-level module, the DataWriter.

You might at this point question and might have truly experienced that designing with abstraction is sometimes overkill. In many cases, the requirement is rigid and unlikely to change too often. It is a trade-off, as to how far we go and how much time we spend on a good design. It may be quite important to get a reasonable designs out to the developers and let the project get on. True, but again if you look at any project, you will often find distinct layers of application components. They may typically be like this:

High-level policy objects holding different piece of business logic or common functionality across different modules.
The Policy level components use some middle layer objects to perform different business level operations such as sending messages to other components, writing data to some data source etc.
The lowest-level objects are Utility objects, which hold the concrete implementation of different operations.

In my opinion, for a reasonable design, you need to concentrate on the Policy level objects. It is important to get them well designed as a policy can be reused by many other applications. The rest of the layers can be left for now if you have run out of time and resource.

Conclusion

Hope you have understood the power of OO designs following the OCP and DIP. It might need some practice in the initial days of design but once you get it by heart, this becomes easy. The important thing is to consider the alternate scenarios that can arise to break your application design. If you find them, try to see if your design can handle them. If not, think about these principles and you might see some light.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.