·
Use
expressive naming; the names of the function, the parameters, and the variables
should indicate their purpose. Use Java naming conventions.
·
Code only against a design – decide how
your program will be structured before you code.
·
Specify precisely what each method
accomplishes.
·
Before testing, satisfy yourself that
the code you have typed is correct. Read
it meticulously.
·
“Correct”
means that it accomplishes what’s required of it.
·
This
is author inspection.
·
Build-a-little-test-a-little:
1.
Add
a relatively small amount of code (“build-a-little”).
2.
Read
what you have typed and correct it if necessary until you are totally satisfied
it’s correct.
3.
[Execute].
4.
Test
the new functionality.
from Braude, E., Software Design, NY:John
Wiley & Sons, Inc., 2004, p. 10.
·
Use
expressive naming; the names of the function, the parameters, and the variables
should indicate their purpose
·
Avoid
global variables: consider passing parameters instead
·
Defend
against bad data
·
Don’t
use parameters as method variables
·
Give
names to numbers
o
e.g.,
private static final int NUM_CELLS 8927;
·
Limit
number of parameters to 6 or 7
·
Introduce
variables near their first use
·
Initialize
all variables
·
Check
loop counters, especially for range correctness
·
Avoid
nesting loops more than 3 levels
·
Ensure
loop termination
·
Inspect
before testing
from Braude, E., Software Design, NY:John
Wiley & Sons, Inc., 2004, p. 28.
·
A
class should capture one and only one
key abstraction.
·
Keep
related data and behavior in one place.
·
All
data should be hidden within its class.
·
Spin
off non-related information into another class.
·
Do
not clutter the public interface of a class with things that users of that
class are not able to use or are not interested in using.
·
Be
sure the abstractions that you model are classes and not simply the roles
objects play.
·
Do
not create “god” classes/objects in
your system. Be very suspicious of an abstraction whose name
contains Driver, Manager, System, or Subsystem.
· In applications which consist of an object-oriented model interacting with a user interface, the model (i.e., the business logic/processing) should never be dependent on the interface. The interface should be dependent on the model.
from Reil, A.J., Object-Oriented
Design Heuristics, NY:Addison-Wesley, 1996.
Control classes model sequencing behavior specific to one or more use cases. Control classes coordinate the events needed to realize the behavior specified in the use cases. You can think of a control class as "running" or "executing" the use case - they represent the dynamics of the use case.
In the early stages of the Elaboration Phase (i.e., requirements more-or-less) a control class is added for each actor/use case pair. The control class is responsible for the flow of events in the user case.
The use of control classes is very subjective. Many authors feel that the use of control classes results in behavior being separated from data. This can happen if your control classes are not chosen wisely. If a control class is doing more than sequencing, then it is doing too much! For example, in the Course Registration System, a student selects a course offering and if the course offering is available, the student is added to it. Who knows how to add the student - the control class or the course offering? The right answer is the course offering. The control class knows when the student should be added; the course offering knows how to add the student. A bad control class would not only know when to add the student but how to add the student.
The addition of a control class per actor/use case pair is only an initial cut - as analysis and design continues, control classes may be eliminated, split up, or combined.
from Quatrani,T., Visual Modeling with Rational Rose 2002 and UML, Boston: Addison-Wesley, 2003, p. 58.