Developer's Daily Java Education
  front page | java | perl | unix | DevDirectory
   
Front Page
Java
Education
Pure Java
Articles
   

The art of Java software design (part 1)
by E Ming Tan
 

Introduction

It is true that you don't need a computer degree to know how to program.  However to do it with a quality that allows easy maintenance and changes is another matter.

According to Software Engineering (SE) principles, a software product life-cycle consists of these phases:

    1. Analysis
    2. Design
    3. Implementation
    4. Testing
Unfortunately, most programmers tend to spend most of the time on the latter two phases while forgetting, or giving less emphasis, to the former two. This is not the right approach, specifically for the implementation phase.  This phase should constitute the least of the whole development time. Unfortunately, part of the reason why developers have to spend so much time and effort on Implementation (and later in Testing) is not having a good design in the first place.
 

Focus on the Design Phase

In this article, I'm assuming that you fully understand the Requirement Analysis phase of the software development, and I'm just going to put the focus on the Design phase of a software product.

According to Object Oriented Analysis and Design (OOAD) in SE principles, objects in a system should exhibit two most important properties.  They are:

    1. High cohesiveness
    2. Low coupling
There are various ways to design highly cohesive and lowly coupled objects in Java.  The way that I would like to share with you is based on the Java 1.1 Delegation Event Model.
 

Sample design of two "radio" objects

Let's examine the Java 1.1 Delegation Event Model by designing two objects to simulate the way an AM/FM radio system works in the real world.  I name these objects "radio broadcaster" and "radio listener", based on their roles in the design.  These names come from the analogy that radio broadcasting stations play in our daily life.  In a given country (equivalent to a software product), anybody (objects) can set up a radio station if he/she has enough resources and presumably is qualified.

If one chooses to set up a radio station and become a radio broadcaster, one becomes a source of information (an object that provides a new service for the system) for other people, i.e., the audience.

The audience, or radio listeners, are those that consume this information.  In this analogy, these are objects that need the service from the radio broadcaster.
 

Dynamic object, stable object

In real life, radio programs change every day, yet the interests of the radio listeners tends to be the same.  As an example, if a person normally likes financial news, you can safely assume that he will will not hate the financial news tomorrow and choose entertainment news instead.  Therefore, because the radio listener does not change as often as the radio programs, in this design, the radio broadcasters' role will be reserved for those objects that constitute the dynamic part of the software components.

From the standpoint of a company developing software, a new employee who just joined a company or has not had enough understanding of an existing software product is suitable for developing radio broadcaster objects.  It can be a child or a subclass that provides new services for the system.

At this point, I guess you may have realized the part of the software components that will be assigned radio listeners role.  Yes, radio listeners are reserved for those objects/classes that construct the core components or base framework of the whole software system.  These radio listeners should be the part of the objects that are most likely to be stable and require the fewest changes (if any) of the software system.  A parent (superclass) or a container object that needs to be extended to
provide new functionality is one of those objects.

Although this role participation should not be rigid since any objects can be radio listeners or radio broadcaster in this design model, remember that it is always good to plan earlier and choose wisely, so as not to affect the total development efforts in the later phases.

(to be continued ...)
 

 
About the author

E Ming Tan is currently with LearningByte International, Minneapolis MN, as a Java consultant. He's developing Java-based (Swing/JFC) multimedia courseware components, and can be reached at eming@learningbyte.com.

 

 
 
No part of these documents may be reproduced or retransmitted
without the prior written permission from the author.
© Copyright 1998 E Ming Tan.  All Rights Reserved.