COHESION WORST TO BEST
Cohesion is a measure of how strongly related the various
responsibilities (operations, methods) of a software module (class,
etc.) are. High cohesion results in robust, reliable, reusable and
understandable code. Low cohesion results in difficulties with
maintenance, testing, reuse and understanding difficulties. (Do
any of
these ring a bell with JINI?)
1. Coincidental: no relation
2. Logical: grouping, for example, by IO routines even though
different
in nature.
3. Temporal: grouped by when they are processed.
4. Communicational: grouped because they operate on the same data.
5. Sequential: grouped because the output of one part is the input
of
another part like an assembly.
6. Functional: grouped because they all contribute to a well-defined
task, e.g., calculating the sine of an angle.
COUPLING WORST TO BEST
Coupling is the degree to which a module relies on other modules.
High,
tight, strong coupling contrasted with low, loose, weak coupling.
Low
coupling is when a module interacts with another module and does not
need to be concerned with the other module's internal implementation.
1. Content: one module relies on the internal workings of another
module so that changing the second module produces data will lead to
changing the first module.
2. Common: two modules share the same global data.
3. External: two modules share an externally imposed data format,
communication, protocol or device interface.
4. Control: one module controls the logic of another by passing it
information on what to do.
5. Stamp: modules share a composite data structure and use only
part of
it, e.g., passing a whole record but only needing part of it.
6. Message: modules are not dependent and use a public interface to
exchange parameterless messages or event.
Various technical levels have tight and loose coupling:
TECHNICAL LEVEL
A. physical - tight is a direct physical link - loose is a physical
intermediary.
B. communication style - tight is synchronous - loose is asynchronous
C. type system - strong type (interfgace semantics) - weak typing
(payload semantics)
D. interaction pattern - OO style naviation or complex object trees -
data-centric self-contained messages.
E. Control of process logic - statically bound services - dynamically
bound services
F. Service discovery and binding - strong OS and lanaguage
dependencies
- OS and language independent
G. Platform dependencies
H. Time - compile time binding - runtime binding.
What I suggested was putting in JavaSpaces all the interfaces that
are
part of the JavaSpaces functionality.
