Michael McGrady wrote: > 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. >
The trouble is that they are also part of Lookup 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 > mmcgr...@topiatechnology.com > > > > >
