The Five Pillars of Reusable Software Design, Explained

UPI Study › Courses › Data Structures and Algorithms › Free lessons › Lesson 3.1 Free with a free account

The Five Pillars of Reusable Software Design

Data Structures and Algorithms · Chapter 3: Thinking in ObjectsSection 3.1 · lesson 7 of 8710 min · free with a free account

← Documenting Your Code for Clarity and Team CollaborationNext lesson: Modeling Real-World Entities as Programmable Objects →

Earn 3 college credits for Data Structures and AlgorithmsRecommended for credit by NCCRS · Computer Science 251 · self-paced · one payment, lifetime access
Enroll in Data Structures and Algorithms · $250 →Download the syllabus (PDF)

In this lesson

Five design ideas that make software robust, adaptable and reusable.

  • Explain the design goals of robustness, adaptability and reusability
  • Describe abstraction, encapsulation, inheritance, polymorphism and modularity
  • Apply the is-a test to decide when inheritance fits
  • Distinguish commonly confused pillars using quick tests

Free study notes

Get this lesson's notes by email

The key points and 4 practice questions with answers, in your inbox. One email, free.

One email. Unsubscribe in one click.

Transcript

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

Opening Question

Adding Audiobooks to a Library

A school library runs on a small lending program, and it works. Then the librarian asks: can we lend audiobooks too? In one design, that request means rewriting the lending desk, the fines, and the catalog. In another, it means adding one new type, and nothing that already worked changes at all. Same features, very different futures. What makes the second design so much easier to grow?

Key Terms

Objects and Types Defined

This lesson is the map before the details: five ideas called pillars, and the three goals they serve. No code yet. Two words will come up constantly. An object is a bundle of data and actions that represents one thing in a program, such as a single library book. A type is a blueprint that describes what a kind of object contains, and what it can do.

Design Goals

Robustness, Adaptability and Reusability

Software designers judge a design by three goals. Robustness: does the program keep working when something unexpected happens, like bad input, or a misused feature? Think of a sturdy phone case. Without it: crashes, wrong results, damaged data. Adaptability: can the program change smoothly when requirements change? Think of a power strip: add another plug, without rewiring the house. Without it, every new feature means rewriting code that worked. Reusability: can parts be used again, in other programs? Think of standard bricks that fit any model. Without it, code is copied again and again, and every copy needs its own fixes. These goals can pull in different directions, so a good design finds a sensible balance.

Overview

Five Pillars of Design

The five pillars are the tools designers use to reach those goals: abstraction, encapsulation, inheritance, polymorphism, and modularity. Each is an idea about how to organize code. For now, focus on what each means, and why it helps.

Pillar One

Abstraction Shows What Matters

Abstraction: show what matters, and hide the rest. When you drive, the dashboard shows speed and fuel. It doesn't show every spark inside the engine. A map works the same way. It leaves out most of the real world, so you can find your way. In software, an abstraction is a simple description of what a part does, kept separate from how it does it. Anyone using the part needs only the description. So the inner workings can be improved later without disturbing anyone, which is adaptability. And one description can serve many programs, which is reusability.

Pillar Two

Encapsulation Guards the Data

Encapsulation: keep an object's data together with the actions that work on it, and let the outside world change the data only through those approved actions. A bank machine is a good picture. You can ask it to withdraw money, but you can't reach inside and change your balance. The balance is protected, and the withdraw action checks the rules before changing it. Every change passes through approved actions, so mistakes and misuse are caught in one place. That's robustness.

Pillar Three

Inheritance and the Is-a Test

Inheritance: build a new type on an existing one. The new type starts with everything the old one offers, and adds or adjusts only what's different. A smartphone is a kind of phone. It makes calls like any phone, and adds apps and a camera. The existing type is the parent, and the new one is the child. A quick check is the is-a test. Say aloud: a child is a kind of parent. A smartphone is a kind of phone, so inheritance fits. A car is not a kind of engine. It has an engine. So inheritance does not fit. The payoff: shared behavior is written once, and reused by every child type. That's reusability.

Pillar Four

One Request, Many Responses

Polymorphism: different kinds of objects receive the same request, and each responds in its own way. Think of the play button on a remote. Pressed, it starts music on a speaker, a film on a television, and a track on a radio. The person pressing the button doesn't need to know which device is listening. So the code that sends a request doesn't change when a new kind of object appears. That's adaptability.

Pillar Five

Modules Like Kitchen Stations

Modularity: divide a large program into separate parts, called modules. Each has one clear job, and talks to the others through a few well-defined requests. A restaurant kitchen works this way. The grill station, the salad station and the pastry station each do their own work, and pass finished plates to the same counter. If the pastry chef changes a recipe, the grill station doesn't notice. A fault or a change stays inside one module, which is robustness. Modules can be swapped or extended, which is adaptability. And a well-built module can move to another project: reusability.

Quick Check

A Score Guarded by Add Points

Quick check. In a video game, a player's score can change only through an add points action, and that action refuses negative points. Which pillar is that? Pause, and decide. Encapsulation. The score is data, guarded by an approved action that checks every request, just like the balance behind a bank machine's withdraw. It isn't mainly abstraction, which is about simplifying a description. And nothing here splits a system into modules.

Case Study

Splitting the Library Into Modules

Pillars are easiest to understand when they work together. So back to the school library, where members borrow books, DVDs and magazines. Modularity comes first. The designer splits the system into three modules: a catalog that tracks items, a members module that tracks borrowers, and a fines module for late charges. A lending desk coordinates them, by sending short requests, and each module sticks to its own job.

Case Study

Describing and Guarding a Library Item

Abstraction decides what an item is. Every borrowable thing is a library item, described by its essentials only: a title, whether it's available, and three actions: borrow, return, and ask for the due date. The color of a cover is left out, because lending doesn't depend on it. Encapsulation guards the item's data. Its status, due date and current borrower are hidden inside it, and they change only through the approved actions, which check the rules first. An item that's already on loan can't be borrowed again. That rule is written once, in one place.

Case Study

Books, DVDs and Magazines as Items

Inheritance reuses the shared parts. A book, a DVD and a magazine are each a kind of library item, so they pass the is-a test. They inherit borrowing and returning exactly as they are, and add only what's special: an author, a running time, an issue number. Then polymorphism lets the desk treat every item alike. The desk asks any item for its due date. A book answers with one loan period, a DVD with a shorter one, and a magazine with a shorter one still. The desk never checks which kind of item it's holding.

Payoff

Audiobooks Without Changing the Desk

Now back to the librarian's question. To add audiobooks, add one new child type: an audiobook is a library item. The lending desk keeps working, unchanged. That's adaptability. The design is robust: invalid actions are rejected in one place, and a problem inside fines can't damage the catalog. And it's reusable: the library item blueprint could serve a tool-lending shop, or a bicycle rental, with little change.

Telling Them Apart

Quick Tests for Similar Pillars

Some pillars are easy to confuse, and each pair has a quick test. Abstraction or encapsulation? Am I simplifying the description? That's abstraction. Am I locking the data behind checked actions? That's encapsulation. Inheritance or polymorphism? Am I reusing what a parent provides, or do different objects answer the same request in different ways? Modularity or inheritance? Are these parts side by side, cooperating? Or is one a kind of the other?

Quick Check

A Payments Rewrite Nobody Noticed

Quick check, with a new system. A music app has a player, a library, and a payments part. Each talks to the others only through a few requests. The payments team rewrites its code from scratch, and the player team never notices. Which pillar made that possible? Pause, and decide. Modularity. The parts sit side by side, each with one job and a small set of requests, so a change inside one stays inside it. No part here is a kind of another, so it isn't inheritance. And no single request gets different answers from different kinds of objects, so it isn't polymorphism.

Key Takeaways

Three Goals, Five Pillars

To summarize. Good design is judged by three goals: robustness, adaptability, and reusability. The five pillars reach them: abstraction hides detail, and encapsulation protects data. Inheritance builds on a parent, and passes the is-a test. Polymorphism lets one request work for many types, without changing the sender. And modularity keeps faults and changes inside clear boundaries. The pillars work best together.

Think About It

Finding a Pillar in Everyday Apps

Something to think about. Pick a system you use every day, such as a music app or an online shop, and one pillar. Where do you think that pillar appears? And what would get harder for its developers, if they had ignored it?

About Data Structures and Algorithms at UPI Study

Data Structures and Algorithms (Computer Science 251) is a self-paced online course of 87 video lessons in 17 chapters, from Java and object-oriented design to arrays, linked lists, recursion, stacks and queues, trees, heaps, hash tables, sorting and graphs. 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: Discrete Math vs Data Structures and Algorithms · Intro to Java vs Data Structures and Algorithms

Why take it here

Why students take Data Structures and Algorithms with UPI Study

How programs store and search dataData Structures and Algorithms teaches how to organize data and measure how fast code runs: arrays, linked lists, stacks, queues, trees, heaps, hash tables, sorting and graphs, all written in Java. 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

Data Structures and Algorithms 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 The Five Pillars of Reusable Software Design

What are the pillars of object-oriented design?
The four ideas most often called the pillars of object-oriented design are abstraction, encapsulation, inheritance and polymorphism, and some courses add modularity as a fifth; together they help software become robust, adaptable and reusable. Abstraction shows what matters and hides the rest, and encapsulation protects data behind checked actions. Inheritance builds a new type on an existing one, polymorphism lets different objects answer the same request in their own ways, and modularity splits a program into parts with clear jobs.
What is the difference between abstraction and encapsulation?
Abstraction simplifies the description of a part, showing what it does while hiding how it does it, like a dashboard that shows speed and fuel but not the engine. Encapsulation keeps data together with the actions that work on it and lets outside code change the data only through approved, checked actions, like a bank machine that lets you withdraw money but never lets you edit your balance.
What is the is-a test for inheritance?
The is-a test checks whether inheritance fits by saying aloud that the child is a kind of the parent. A smartphone is a kind of phone, so a smartphone type can inherit from a phone type. A car is not a kind of engine, because it has an engine. That has-a relationship means the car should hold an engine inside it rather than inherit from it.
What do robustness, adaptability and reusability mean in software design?
They are three goals for judging a design. Robustness means the program keeps working when something unexpected happens, such as bad input or a misused feature. Adaptability means it can change smoothly when requirements change, without rewriting code that already worked. Reusability means parts can be used again in other programs instead of being copied. The goals can pull in different directions, so good designs balance them.

About the Data Structures and Algorithms course

How many college credits is Data Structures and Algorithms?
Data Structures and Algorithms (Computer Science 251) 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 Data Structures and Algorithms cost and what is included?
$250, paid once, with lifetime access: all 87 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 Data Structures and Algorithms take?
It is self-paced with no deadlines. The 87 lessons total about 15 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 Data Structures and Algorithms.

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

Enroll in Data Structures and Algorithms →Download the syllabusEvery course with PRO →
Data Structures and Algorithms
3 credits · NCCRSEnroll →