Chapter 17 - Visibility and Dependency

Intro
• Interconnected nature of conventially created software is major obstacle in creating reusable software components.
• Lots of "rules" for avoiding these interconnections (at least the most harmful ones) in software engineering.
• Visibility
  • characterization of names - handles by which objects are accessed
  • An object is visible if its name is legal and denotes the object.
  • Scope - if object is in scope, it is visible
  • Reducing visibility of a variable reduces (or at least limits) the connectedness of the object
• Dependency
  • Relates on portion of a system to another.
  • If one module cannot exist in a meaningful way without another module, the module is dependent.
  • Child classes are dependent on the parent.

1. Coupling and Cohesion
   • Coupling - the relationship between modules in a software system.
   • Cohesion - the relationships within a module
   • Reduction in interconnectedness = reduce coupling and increase cohesion
   • Varieties of Coupling (from bad to "good")
     • Internal Data Coupling - one module (class) modifies the local data values in another class - (note: friend classes can do this)
     • Global Data Coupling - two or modules (classes) are bound together by their reliance on common global data structures. In oop world, could create a manager class to "handle" the data that needs to be accessed which defines how that "global" data is accessed - this reduces global data coupling to parameter coupling which is completely acceptable.
       • Global Variables with file scope - can only be used within file.
       • Global Variables with program scope - can be used by the entire program.
     • Control (or sequence) Coupling - One module must perform operations in some fixed order but the order is controlled by another module. This indicates that the designer of the module was using too low a level of abstraction in the design. The module needing sequencing needs to make sure itself that the sequencing is correct rather than relying on other modules to do it.
     • Parameter Coupling - one module must invoke the services and routines of another BUT the only relationship between the two is the number and type of parameters supplied and the type of value returned. Very common, easy to understand, easy to see, easy to verify statically (compile time), very useful.
     • Subclass Coupling - inheritance demands dependency so unavoidable if using it. Again, another "good" coupling. However, only good if inheritance is appropriate.
   • Varieties of Cohesion - (bad to good)
     • Coincidental Cohesion - elements of a module are grouped for no apparent reason. - usually programmer just dumps a bunch of stuff in a module for no good reason other than to have a module. Sign of a poor design. Objects have unrelated methods.
     • Logical Cohesion - there is a logical connection between the elements but no actual connections based on data or control. - This is typical of libraries. They do make sense.
     • Temporal Cohesion - the elements are bound together simply because they all do "something" at the same time. Initialization of all the data for example. Better to have the modules deal with their own initialization.
     • Communication Cohesion - elements are grouped together because they must all use the same input/output data or devices. Usually, this ends up being a manager and should be designed as such.
     • Sequential Cohesion - usually a result of trying to get rid of sequential coupling. Still indicates design based on too low a level of design.
     • Functional Cohesion - desirable since all the functions are grouped because they all work together to produce a "single function". In classes the function is to USE the class.
     • Data Cohesion - a module internally defines a set of data values and exports (makes visible) a set of methods to manipulate that data - basis of good ADT

       Estimating degree of cohesion by writing a statement of purpose

       • Sentence containing a comma or more than 1 verb are probably performing more than one function - sequential or communication cohesion is probable.
       • If the sentence contains words like "first", "next", "after", etc. then sequential or temporal cohesion is probable.
       • If the predicate does not contain a specific, single object; then logical cohesion is probable.
       • If sentence contains words like "initialize" or "clean-up", then temporal cohesion is probable.
   • Coupling and Cohesion in Object-Oriented Systems - design ideas for general modules are applicable to classes (ie objects). Ideal is a highly cohesive object that has a specific well designed purpose that is self-sufficient (ie. doesn't depend on other objects.)
   • The Law of Demeter
     • Rules are not mandated - they are simply guidelines to help alleviate a problem
     • Modules should exhibit interal cohesion and minimize external coupling. (Attempt to have the ideal of independent objects.)
     • No procedure can have more than 60 lines of code. (Real purpose was to keep them small and easily readable and on one "page". Improve readability, understanding, thus decrease maintenance and improve realiability.)
     • No goto's allowed. (Misused Goto's tend to reduce readability, reliability, and increase maintenance. Goto's are VERY easy to misuse.)
     • Law of Demeter - specific to Object-Oriented programming -
       • Weak form - Inside a method, data can be accessed in the messages can be sent to only the following objects
         1. Arguments associated with the method being executed (including the self object.
         2. Instance variables for the receiver of the method.
         3. Global variables, both with file scope and with program scope.
         4. Temporary variables created inside the method.
       • Strong form - Inside a method it is permitted to access or send messages only to the following objects.
         1. Arguments associated with the method being executed (including the self object.
         2. Instance variables defined in the class containing the method being executed.
         3. Global variables.
         4. Temporary variables created inside the method.
   • Class-Level vs. Object-Level Visibility
     • Class-level Visibility - (C++) - 2 instantiations of the same class can modify each others private values. Rational a, b; Passing b.add(a) - b has direct access to a's values.
     • Object-Level Visibility - each instance of an object is unique and has no access to any other object's values even those of another instance of the same class.
   • Active Values - variable on which we want to do something every time its value changes - see discussion
2. Subclass Clients and User Clients
   • Private - only the object has direct access to these elements
   • Protected - only the object and its descendants have direct access to these elements - Subclass Clients are the descendants - "Subclass clients create new classes based on the original class."
   • Public - everyone has access to these - this is the interface - used by User Clients. "User clients create instances of the class and pass messages to these objects."
3. Control of Access and Visibility
   • Visibility in Smalltalk
   • Visibility in Object Pascal
   • Visibility in C++
     • Sibling Instances
     • Private Inheritance
     • Friend Functions
     • Name Spaces
     • Interaction between Overloading and Overriding
   • Visibility in Java
   • Visibility in Objective-C
4. Intentional Dependency