Loading ...
Sorry, an error occurred while loading the content.

Re: coupling and cohesion

Expand Messages
  • alshalloway
    I would say that what you ve described is accurate, but only partly so. They are examples of coupling and cohesion - not the whole story. Here is some
    Message 1 of 5 , Jan 19, 2002
    • 0 Attachment
      I would say that what you've described is accurate, but only partly
      so. They are examples of coupling and cohesion - not the whole
      story. Here is some content from my talk that defines coupling and
      cohesion.

      Cohesion refers to how "closely the operations in a routine are
      related." I have heard other people refer to cohesion as "clarity"
      because the more operations are related in a routine (or class) the
      easier it is to understand things.

      High cohesion is related to clarity and understanding.

      This is from Steve McConnell, Code Complete, 1993, pg 81 (this
      concept was first described by Larry Constantine in 1975, but we like
      McConnell's defintion best)

      Coupling refers "to the strength of a connection between two
      routines. Coupling is a complement to cohesion. Cohesion describes
      how strongly the internal contents of a routine are related to each
      other. Coupling describes how strongly a routine is related to other
      routines. The goal is to create routines with internal integrity
      (strong cohesion) and small, direct, visible, and flexible relations
      to other routines (loose coupling)."

      Tight coupling is related to highly interconnected code.

      From Steve McConnell, Code Complete, 1993, pg 81(this concept was
      first described by Larry Constantine in 1975, but we like McConnell's
      defintion best)

      Hope this helps.
      Alan Shalloway
    • altmrrelaxed
      ... like ... other ... relations ... McConnell s ... Thanks for the reply, I read McConnell again and the different flavors of cohesion and coupling. I think I
      Message 2 of 5 , Jan 19, 2002
      • 0 Attachment
        --- In dpexplained@y..., "alshalloway" <alshall@n...> wrote:
        > I would say that what you've described is accurate, but only partly
        > so. They are examples of coupling and cohesion - not the whole
        > story. Here is some content from my talk that defines coupling and
        > cohesion.
        >
        > Cohesion refers to how "closely the operations in a routine are
        > related." I have heard other people refer to cohesion as "clarity"
        > because the more operations are related in a routine (or class) the
        > easier it is to understand things.
        >
        > High cohesion is related to clarity and understanding.
        >
        > This is from Steve McConnell, Code Complete, 1993, pg 81 (this
        > concept was first described by Larry Constantine in 1975, but we
        like
        > McConnell's defintion best)
        >
        > Coupling refers "to the strength of a connection between two
        > routines. Coupling is a complement to cohesion. Cohesion describes
        > how strongly the internal contents of a routine are related to each
        > other. Coupling describes how strongly a routine is related to
        other
        > routines. The goal is to create routines with internal integrity
        > (strong cohesion) and small, direct, visible, and flexible
        relations
        > to other routines (loose coupling)."
        >
        > Tight coupling is related to highly interconnected code.
        >
        > From Steve McConnell, Code Complete, 1993, pg 81(this concept was
        > first described by Larry Constantine in 1975, but we like
        McConnell's
        > defintion best)
        >
        > Hope this helps.
        > Alan Shalloway
        Thanks for the reply,
        I read McConnell again and the different flavors of cohesion and
        coupling.
        I think I clearly understand the term High Cohesion better now.
        Here are some examples that I came up with.

        A pure function can be said to have high cohesion and low coupling.

        e.g. Convert Fahrenheit to Celsius.

        C = f( F );

        High cohesion because it does one and only one operation.
        Low coupling because it has one input parameter.
        Also note that there is no side effect of the operation; it always
        produces the same result for the same input.

        A class member function can be said to have high cohesion.
        e.g.

        public double getAcceleration() { return _primaryForce / _mass ; }

        High cohesion because it does one and only one operation.
        No coupling because it uses member variables to compute result;
        No side effects.

        A global function with global variables.
        e.g.

        double Forces;
        double masses;
        double GetGlobalAcceleration() { return Forces / masses ; }

        High cohesion because it does one and only one operation;
        Globally coupled because anyone can change the variables.
        No side effects.

        A function with low cohesion and tight coupling, and side effects.
        e.g.

        int sprintf( char * buf, char * format, ... );

        Low cohesion because it does many things to process the format string.
        Tightly coupled because of many parameters.
        Has side effects because the output of primary interest in what is
        returned in the buffer, not the returned character count.

        A function with loose coupling can plug in different objects and get
        different results.
        e.g.

        Factory * aAbsFactory; // abstract class
        Product * createInstance() {
        return aAbsFactory->Create();
        }

        aAbsFactory = & aConcreteDinghyFactory ; // The Plug In
        Product * aConcreteProduct = createInstatnce();

        High cohesion because it does one and only one operation;
        Loosely coupled because the flexibility to plug in different objects
        of the hierarchy.
        No perceived side effects.

        Equivalent instance code.
        Product * aConcreteProduct = aConcreteDinghyFactory.Create();

        I also understand the term Loose Coupling better because of reviewing
        the other types of coupling.

        Sincerely, Art Pannek
      • Alan Shalloway
        Art: Great. And thanks for the examples. McConnel s book is an interesting example of how these concepts have been around a long time. OO doesn t really
        Message 3 of 5 , Jan 19, 2002
        • 0 Attachment
          Art:
          Great. And thanks for the examples.
          McConnel's book is an interesting example of how these concepts have been
          around a long time.
          OO doesn't really change these, it just gives us a better way of building
          our models. Yet, we're still
          looking at issues of coupling, cohesion and redundancy as we have for 30
          years (or at least as some of us old-timers have :)

          Alan Shalloway
          Sr Consultant, 425-260-8754, http://www.netobjectives.com
          ---------------------------------------------------------
          * Sign up for our free newsletter by sending an e-mail to
          info@...
          * Learn about and join our design pattern community of practice by going to
          www.netobjectives.com/dpexplained
          * Jim Trott's & my book - Design Patterns Explained: A New Perspective on
          Object-Oriented Design is now available
          * Scott Bain's & my new CD based XML training is now available as well

          -----Original Message-----
          From: altmrrelaxed [mailto:mrrelaxed@...]
          Sent: Saturday, January 19, 2002 6:07 PM
          To: dpexplained@yahoogroups.com
          Subject: [dpexplained] Re: coupling and cohesion


          --- In dpexplained@y..., "alshalloway" <alshall@n...> wrote:
          > I would say that what you've described is accurate, but only partly
          > so. They are examples of coupling and cohesion - not the whole
          > story. Here is some content from my talk that defines coupling and
          > cohesion.
          >
          > Cohesion refers to how "closely the operations in a routine are
          > related." I have heard other people refer to cohesion as "clarity"
          > because the more operations are related in a routine (or class) the
          > easier it is to understand things.
          >
          > High cohesion is related to clarity and understanding.
          >
          > This is from Steve McConnell, Code Complete, 1993, pg 81 (this
          > concept was first described by Larry Constantine in 1975, but we
          like
          > McConnell's defintion best)
          >
          > Coupling refers "to the strength of a connection between two
          > routines. Coupling is a complement to cohesion. Cohesion describes
          > how strongly the internal contents of a routine are related to each
          > other. Coupling describes how strongly a routine is related to
          other
          > routines. The goal is to create routines with internal integrity
          > (strong cohesion) and small, direct, visible, and flexible
          relations
          > to other routines (loose coupling)."
          >
          > Tight coupling is related to highly interconnected code.
          >
          > From Steve McConnell, Code Complete, 1993, pg 81(this concept was
          > first described by Larry Constantine in 1975, but we like
          McConnell's
          > defintion best)
          >
          > Hope this helps.
          > Alan Shalloway
          Thanks for the reply,
          I read McConnell again and the different flavors of cohesion and
          coupling.
          I think I clearly understand the term High Cohesion better now.
          Here are some examples that I came up with.

          A pure function can be said to have high cohesion and low coupling.

          e.g. Convert Fahrenheit to Celsius.

          C = f( F );

          High cohesion because it does one and only one operation.
          Low coupling because it has one input parameter.
          Also note that there is no side effect of the operation; it always
          produces the same result for the same input.

          A class member function can be said to have high cohesion.
          e.g.

          public double getAcceleration() { return _primaryForce / _mass ; }

          High cohesion because it does one and only one operation.
          No coupling because it uses member variables to compute result;
          No side effects.

          A global function with global variables.
          e.g.

          double Forces;
          double masses;
          double GetGlobalAcceleration() { return Forces / masses ; }

          High cohesion because it does one and only one operation;
          Globally coupled because anyone can change the variables.
          No side effects.

          A function with low cohesion and tight coupling, and side effects.
          e.g.

          int sprintf( char * buf, char * format, ... );

          Low cohesion because it does many things to process the format string.
          Tightly coupled because of many parameters.
          Has side effects because the output of primary interest in what is
          returned in the buffer, not the returned character count.

          A function with loose coupling can plug in different objects and get
          different results.
          e.g.

          Factory * aAbsFactory; // abstract class
          Product * createInstance() {
          return aAbsFactory->Create();
          }

          aAbsFactory = & aConcreteDinghyFactory ; // The Plug In
          Product * aConcreteProduct = createInstatnce();

          High cohesion because it does one and only one operation;
          Loosely coupled because the flexibility to plug in different objects
          of the hierarchy.
          No perceived side effects.

          Equivalent instance code.
          Product * aConcreteProduct = aConcreteDinghyFactory.Create();

          I also understand the term Loose Coupling better because of reviewing
          the other types of coupling.

          Sincerely, Art Pannek





          To unsubscribe from this group, send an email to:
          dpexplained-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • chadlehmanmyfullname
          Excellent. These were two terms that weren t crystal clear in the book, but by the end were understood. This reinforces the understanding. Chad ... other ...
          Message 4 of 5 , Feb 5, 2002
          • 0 Attachment
            Excellent. These were two terms that weren't crystal clear in the
            book, but by the end were understood. This reinforces the
            understanding.

            Chad

            > I was asked this question off-line, but was given permission to use
            > it so I am posting it here. This was in reference to the free
            > seminar I am doing January 30 in Bellevue, WA on Refactoring, Design
            > Patterns and XP.
            >
            > *********************
            > I've been trying to understand the terms, loose coupling and high
            > cohesion.
            > Here is what I've come up with. Can you explain any better at free
            > seminar?
            >
            > cohesion: stick together. e.g.. use a function aObj.someMethod();
            >
            > high cohesion: one variable, one purpose. e.g.. double
            > primaryAcceleration =
            > _primaryForce / _mass;
            >
            > or one method, one purpose. e.g.. double acceleration =
            > aBody.getAcceleration();
            >
            > Refactoring example "Replace Temp with Query" vital
            > before "Extract Method",
            > M. Fowler, pg. 120.
            >
            > low cohesion: local variables re-used for other purposes.
            >
            > e.g.. double temp, result;
            > temp = ( ... some complicated expression ... );
            > result = temp;
            > temp = ( ... some other expression ... );
            > result = temp / result;
            >
            > coupling: classes become coupled when they use functions of the
            other
            > classes.
            >
            > Ref: AmbySoft Inc. Coding Standards for Java .
            >
            > reduced coupling: smaller public interface.
            >
            > loose coupling: a layer of indirection;
            >
            > derived classes become loosely coupled when they use functions
            of
            > their base
            > class.
            > e.g.. Bridge Pattern base class functions redirect to the
            > implementation.
            >
            > de-couple: add layer of indirection; throw a class at it; abstract
            > way the
            > interface; make class hierarchy.
            >
            > *******************
          Your message has been successfully submitted and would be delivered to recipients shortly.