|
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.
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.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|