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.
Mike
On Dec 10, 2008, at 10:54 AM, Dan Creswell wrote:
Michael McGrady wrote:
+1 This is not, I would stress, to question or to otherwise lessen
the
value of JINI. This is just to allow JavaSpaces to live its "natural
life" and to move what is in JINI but belongs in JavaSpaces to
JavaSpaces so that a Java implementation of Linda spaces can stand on
its own. Then, as Niclas has noted, JINI can use and extend
JavaSpaces
as required.
Could you please explain your logic for placing some of these core
(and
shared across services) classes into JavaSpaces. I hear what you're
saying but at least for me right now it feels like you'd be making a
less cohesive system rather than a better split one.
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[EMAIL PROTECTED]
