Designing Components Around Classes: Principles and Process

UPI Study › Courses › Software Engineering › Free lessons › Lesson 9.3 Free with a free account

Designing Components Around Classes: Principles and Process

Software Engineering · Chapter 9: Component-Level Design and Practical ApplicationSection 9.3 · lesson 63 of 1037 min · free with a free account

← What Goes Into Component-Level DesignNext lesson: Putting Component-Level Design into Practice: Steps and Examples →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

6 principles for judging whether a design will hold up.

  • Explain cohesion and coupling as foundational qualities
  • Apply the open-closed and Liskov substitution principles
  • Apply interface segregation and dependency inversion
  • Use the 6 as criteria for judging a design

Transcript

Everything said in the video, section by section (836 words). Read along, or search it.

Component-Level Design and Practical Application

Designing Components Around Classes

A class diagram can be syntactically correct, and still describe a bad design. This section covers six principles that give component-level design something more specific to aim for than, it works. Cohesion, coupling, open-closed, Liskov substitution, interface segregation, and dependency inversion.

Beyond "It Works"

Correct Syntax, Bad Design

A design that compiles and runs is not automatically a good design. These principles give a way to judge whether a class's responsibilities are well chosen. And whether its relationships to other classes will hold up as the system keeps changing.

The Foundation

Cohesion and Coupling

Two qualities are foundational. Cohesion, and coupling. Cohesion describes how closely related the responsibilities inside a single component are. A highly cohesive component does one clear job. A low-cohesion component stitches several unrelated concerns into one place. Coupling describes how much one component depends on another's internal details. Low coupling means components can change somewhat independently. High coupling means a change in one forces changes elsewhere. Nearly everything else here is a more specific way of pursuing the same goal. High cohesion within a component, and low coupling between them.

Open-Closed

Extend, Don't Edit

The open-closed principle says a component should be open for extension, but closed for modification. It should be possible to add new behavior without editing code that already works. That is usually done through abstraction. A new case becomes a new implementation of an existing interface. It does not become yet another branch, in a growing chain of conditionals inside tested code. Every edit to working code risks breaking something that used to work. Designing for extension avoids that risk.

Liskov Substitution

Is the Substitution Actually Safe?

The Liskov substitution principle says that if one class is a subtype of another, it must be genuinely safe to use the subtype anywhere the supertype is expected. An inheritance relationship can be syntactically valid, and still violate this. The classic example is a square class that inherits from a rectangle class. The square overrides width and height so they always change together. That quietly breaks any code that assumed it could set them independently. It looks like a legitimate is-a relationship on paper. But the substitution is not actually safe.

Interface Segregation

Don't Force Unneeded Dependencies

The interface segregation principle says a component should not be forced, to depend on methods it does not use. Several small, focused interfaces are generally better than one large, general-purpose interface. A large interface forces every class that implements it to deal with its methods, even ones entirely irrelevant to what that class does. It is the same idea as cohesion, applied to the boundary a component presents, rather than what is inside it.

Figure 1

Dependency Inversion

This figure shows dependency inversion. On the left is the naive arrangement. A high-level order policy depends directly on one specific storage class. On the right, the dependency is inverted. The order policy depends on an abstraction, an order store. And the concrete stores, one using a database and one using files, both implement that abstraction. So the storage can be swapped, without touching the policy at all.

Dependency Inversion

Depend on Abstractions, Not Details

The dependency inversion principle says higher-level components, the ones making policy decisions, should not depend directly on the details of lower-level components. Instead, both should depend on a shared abstraction between them. That inverts the naive direction, where a high-level component would be tied to one specific low-level implementation. The payoff is flexibility. A particular way of storing data can be swapped out, without touching the high-level component. It was only ever talking to the shared abstraction in the first place.

Table 1

6 Principles at a Glance

Here are all six principles at a glance. Cohesion is how focused a component's own responsibilities are. Coupling is how much it depends on another's internals. Open-closed means extending behavior without editing working code. Liskov substitution means a subtype must be safe wherever its supertype is expected. Interface segregation means not forcing a component to depend on methods it does not use. And dependency inversion means depending on shared abstractions, not concrete low-level details.

Why This Matters

Criteria for Change, Not for Running

Why do these principles matter, if code that ignores them can still run correctly today? Because they are not requirements for making code run at all. They are the concrete criteria for judging whether a structural or interface decision was actually a good one. Not just whether the code runs, but whether it will hold up as the system keeps changing.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Cohesion is how closely related and focused a component's responsibilities are. Coupling is how much it depends on another component's internal details. The open-closed principle says a component should be extendable, without modifying its existing, working code. The Liskov substitution principle requires a subtype to be genuinely safe to substitute anywhere its supertype is expected. And the dependency inversion principle says high-level and low-level components should both depend on a shared abstraction.

Key Takeaways

What to Carry Forward

To pull this together. Aim for high cohesion inside components, and low coupling between them. Open-closed means adding new implementations, rather than editing working code. Liskov substitution means a valid is-a relationship must also be a safe substitution. Interface segregation favors small, focused interfaces. And dependency inversion means depending on abstractions, so the details can be swapped.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Designing Components Around Classes: Principles and Process

What is the open-closed principle in software design?
The open-closed principle says a component should be open for extension but closed for modification, so new behavior can be added without editing code that already works. It is usually achieved through abstraction: a new case becomes a new implementation of an existing interface rather than another branch in a growing chain of conditionals. This matters because every edit to tested, working code risks breaking something that used to work.
What is the Liskov substitution principle with an example?
The Liskov substitution principle says that if one class is a subtype of another, it must be genuinely safe to use the subtype anywhere the supertype is expected. The classic violation is a Square class inheriting from Rectangle and overriding width and height so they always change together. That breaks any code assuming it can set width and height independently, even though square is-a rectangle looks valid on paper.
What is the interface segregation principle?
The interface segregation principle says a component should not be forced to depend on methods it does not use, so several small, focused interfaces are generally better than one large, general-purpose interface. A large interface forces every implementing class to deal with methods irrelevant to its job. It applies the idea of cohesion to the boundary a component presents, rather than to what is inside the component.
What is the dependency inversion principle?
The dependency inversion principle says high-level components that make policy decisions should not depend directly on low-level details; both should depend on a shared abstraction. For example, an order policy depends on an OrderStore interface, and a database store and a file store both implement it. The storage can then be swapped without touching the policy, because the policy only ever talked to the abstraction.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →