CPSC 210

D1: Cohesion & Coupling

Programming vs. Engineering

  • So far, we have learned how to do object-oriented programming
  • Now, we will start learning how to do object-oriented software engineering 
public class InstantFeedbackQuiz extends Quiz {

    // REQUIRES: questions cannot be an empty list
    // EFFECTS: constructs quiz with given list of questions
    public InstantFeedbackQuiz(QuestionList questions) {
        super(questions);
    }

    // MODIFIES: this
    // EFFECTS: submit an answer to the current question 
    //    and return feedback string
    @Override
    public String submitAnswer(String answer) {
        boolean correct = super.checkAnswer(answer);

        return correct ? "Correct!" : "Incorrect!";
    }
}

a bunch of code

Well-designed software modules

Learning Goals

  • Describe the principle of cohesion
  • Describe the principle of coupling
  • Refactor a system to reduce coupling and improve cohesion
  • Identify instances of high coupling and/or poor cohesion in software design

Cohesion

  • Every class should have one responsibility
  • Assessing cohesion:
    • Graph showing methods
      using fields 
    • Graph has clusters? Low cohesion! Should be split in multiple classes!

Coupling

Tight Coupling

Loose Coupling

  • Measure of degree to which one part of the system depends on other parts
    • Coupling is too tight when you make a change in one class and many other classes break!
    • e.g. you change a method in a class and many other classes will stop compiling

Coupling (2)

  • Moderate Coupling (detected at compile time)
    • Change in class causes error in other class

  • Semantic Coupling (detected at runtime)

    • Class depends on impl. in another class

    • Change in class causes bug in other class

  • Remember Single Point of Control in CPSC 110

    • Changes should be needed only in one place

Let's ask Dr. Google

Let's ask Dr. Google (2)

Lecture Ticket (1)

  • Account  
  • PurchaseManager
  • Purchase
  • BonusManager

Lecture Ticket (2)

  • Semantic coupling between Client and Account
  • We need a helper method like generateDateString()
  • We probably want a new class for dates

Lecture Lab (1)

  • AceCell: cellular network company
  • Each phone assigned to one customer
  • Account can have multiple phones
  • Each account needs one payee for bills
  • Each phone has a call log
  • Monthly billing based on call logs of all phones

Lecture Lab (2)

Your Design

Unnecessary coupling!

Who owns the phone?

Who pays?

For what account?

  1. Is there too much coupling? If so, where?
  2. Can you find other problems in this design?

Lecture Lab (3)

3. Long distance calls!

  • New type InternationalCall and Monthly Statement would need to differentiate
  • Cohesive change: places new functionality in a logical place
  • Possibly introduce hierarchy of call types!

L-L Wrap-Up

  • If design loses cohesion/gains coupling:
    • harder to reason about classes in isolation
    • harder to locate code related to some functionality
    • harder to reuse pieces of functionality outside the system
    • harder to build on for other design concepts

If you find this happening to you...
...look for ways this month's techniques can help!

D1: Cohesion & Coupling

The End - Thank You!

CPSC210 - D1: Cohesion and Coupling

By meghanallen

Source: Steven Wolfman

CPSC210 - D1: Cohesion and Coupling

  • 82

More from meghanallen