Decomposition, Modularity, Cohesion, and Coupling

Learning Objectives

• Break a software system into modules and responsibilities.
• Explain high cohesion and low coupling.
• Recognize god classes and mixed responsibilities.
• Create a first-pass component map for a small system.

Lecture Notes

Decomposition is the process of breaking a system into smaller parts. This is not just about creating more files. A bad decomposition can make a system more confusing. A good decomposition creates parts that match the main ideas of the problem: users, orders, tasks, products, payments, reports, courses, grades, or game entities.

Separation of concerns means each part of the software focuses on one concern. In a web app, display concerns should not be mixed with payment rules. In a game, rendering should not be mixed with save-file parsing. In a student planner, due-date calculation should not be hidden in a button click handler. When concerns are separated, the system is easier to test and change.

Cohesion describes how well the contents of a module belong together. A highly cohesive Cart module contains cart items, quantity updates, totals, and cart validation. A low-cohesion UtilityManager that validates emails, calculates tax, writes logs, and updates the screen has no clear purpose. Low cohesion is a warning sign that the code was grouped by convenience instead of meaning.

Coupling describes dependency between parts. Some coupling is necessary. A CheckoutService must use pricing and payment in some way. The problem is unnecessary or concrete coupling. If CheckoutService directly creates a StripePaymentGateway, it becomes harder to test and harder to swap payment providers. If it depends on a PaymentProcessor interface, the design becomes more flexible.

A practical decomposition process is to list nouns and verbs from requirements. Nouns often suggest data or modules: Student, Course, Assignment, Reminder. Verbs suggest behavior: enroll, submit, notify, calculate, export. Then group behavior near the data or policy it belongs with. This is not a perfect algorithm, but it helps students move from vague requirements to a workable design.

Worked Example: Decomposing a student planner

StudentPlannerApp
- stores courses
- draws the dashboard
- sends reminders
- saves files
- calculates overdue tasks
- imports calendar events
- validates task names
- prints reports

TaskRepository
- saves and loads tasks

TaskService
- creates tasks
- marks tasks complete
- validates task rules

ScheduleService
- finds overdue and upcoming tasks
- handles recurring due dates

ReminderService
- decides when reminders should be sent

DashboardView
- displays task groups to the user

Lab: Modular Refactor Plan

Scenario: You are given a single-file gradebook app. It reads scores, calculates grades, saves results, and prints reports.

Steps

1. Identify every responsibility in the file.
2. Group related responsibilities into modules.
3. Draw arrows showing dependencies between modules.
4. Find at least two dependencies that should be inverted or removed.
5. Write a refactor order that avoids breaking behavior.

Deliverables

• Responsibility list
• Module map
• Dependency sketch
• Refactor plan

Assignment

Design a module breakdown for your capstone idea. Include at least six modules/classes and describe how they communicate.

Discussion Prompts

• Can a system have too many modules?
• What makes a module name good or bad?
• Should modules be based on technical layers or business concepts?

Week 3 Quiz

Use these as quick checks after the lesson.

Student Notes

Saved in this browser only.