UPI Study › Courses › C++ Programming › Free lessons › Lesson 3.1 Free with a free account
Procedure-Driven vs. Object-Driven
C++ Programming · Chapter 3: Program Design and the Object ModelSection 3.1 · lesson 16 of 84video coming soon
← Number Crunching in CodeNext lesson: Anatomy of OOP →
In this lesson
Two ways to cut the same problem, side by side.
- Describe procedural and object decomposition
- Say where data lives and who may touch it
- Predict how a change ripples through each design
- Choose a style per part, not per program
Transcript
Everything said in the video, section by section (1,250 words). Read along, or search it.
Opening Question
Two Ways to Describe a Restaurant
Every design begins with the same question: what are the pieces? Imagine describing a restaurant to someone who's never seen one. You could describe it as a sequence of activities: take the order, cook the food, serve it, collect payment. Or as a set of participants: a waiter who takes orders and serves, a kitchen that holds stock and cooks, and a till that handles the money. Both descriptions are accurate. They divide the same reality along different lines.
Key Term
Decomposition and Two Competing Styles
Program design offers exactly this choice. Decomposition means breaking a problem into parts small enough to build and check, one at a time. And the two dominant styles disagree about what a part should be.
Procedure-Driven
The Verb as Unit of Design
In a procedure-driven design, the program is a collection of operations. Data sits in records apart from them, and any operation that needs it reaches for it. The unit of design is the verb. For a car park: admit vehicle, find free bay, compute fee and release bay, all around a shared store of bays, tickets and the tariff. Each operation is easy to write and test in isolation, because it takes what it needs and returns a result. But the data is exposed to all of them equally. Every arrow into the shared data is permission to read it, and to change it. Nothing says which operations may change the tariff, so nothing prevents one that shouldn't. It's quick to extend, until there are more arrows than one person can hold in mind.
Object-Driven
The Noun as Unit of Design
In an object-driven design, the data and the operations on it are bundled into single units. Each unit keeps its own data, and offers things it will do on request. The rest of the program asks it to act, rather than reaching in. The unit of design is the noun. The garage holds its bays and the tariff, and will admit a vehicle, or release a ticket. A bay holds its number and whether it's occupied. It can say whether it's free, or be occupied, or vacated. A ticket holds its entry time and its bay, and can report its own fee. To learn a fee, you ask the ticket. The ticket owns the answer.
Side-by-Side Comparison
Same Car Park Jobs, Two Designs
Here are the same jobs, done by each design. To park a vehicle, design A's admit vehicle searches the shared bay list, and writes to both shared lists. In design B, the garage asks its bays which are free, and hands back a ticket. To work out a fee, design A looks the ticket up in a shared list, and reads the shared tariff. Design B asks the ticket for its own fee. To free a bay, design A edits both lists, and must keep them consistent. In design B, each unit keeps only its own state correct. The last two rows hold the whole argument. Design A spreads knowledge of the data across every function that uses it. Design B concentrates it. With four functions, the difference is almost cosmetic. At forty, it becomes decisive.
Quick Check
Where the Motorcycle Rate Change Lands
Quick check. A new rule arrives: motorcycles pay a lower rate. In which design does that change stay in one place? Pause, and decide. Design B. The ticket owns its fee calculation, so the change stays inside it. Design A adds a vehicle type to the ticket record, then edits every operation that reads a ticket.
Change Over Time
Judging Designs by Their Changes
Designs aren't judged on the day they're written. They're judged every time someone changes them. Add monthly pass holders, who park free. Design A must find every place a fee is computed. Design B adds a second kind of ticket that answers the fee question differently. When a fee comes out wrong, design A makes every function with access to the tariff a suspect. Design B searches one unit. And when two people work at once, design A's shared structures make their changes collide.
Key Terms
Ripple Effects and Coupling
That pattern is called a ripple effect: a change in one place forcing changes in others. Ripples aren't caused by procedures as such. They're caused by many parts depending on the same changeable data. The measure of that dependence is coupling: how much one part must know about another. Low coupling is the real goal, and the object model is one well-tested way to get it.
Effort Graph
Where the Effort Lines Cross
Effort per change is the honest yardstick, and both approaches start cheap. This picture is schematic, not measured. The procedure-driven line starts low, but climbs steeply. The object-driven line starts higher, but climbs slowly. Below the crossing point, procedures win: there's less structure to set up, less to read, and nothing yet to protect. Above it, the object design's flatter slope repays its higher starting cost. The axes carry no numbers, on purpose. Where the lines cross depends on the problem and the people.
Deciding Factors
Conditions That Favor Each Style
Several conditions push a design one way or the other. A few hundred lines that one person can hold in mind favor procedures. Thousands of lines, growing, favor objects. One or two kinds of data, handled uniformly, favor procedures. Many kinds, each with its own rules about what's valid, favor objects. Code written once and discarded favors procedures. Code maintained for years by people who didn't write it, and teams working in parallel, favor objects.
Common Mistake
Objects Are Not Automatically Better
But objects aren't automatically better. A badly divided object design is worse than a well-organized procedural one. Cut the units along the wrong lines, and every request needs three others to answer it: all the ceremony, and none of the containment. Judge a design by how much one part must know about another, not by the style it claims.
C++ in Practice
A Multi-Paradigm Language Per Part
Some languages take a position. C++ doesn't. It's a multi-paradigm language: plain functions and self-contained units stand side by side, even in one file. Converting a temperature, or sorting a list, holds nothing between calls, so it's clearest as a plain function. A bank account, a bay or a connection has state, and rules about which states are legal. Keeping the rules next to the state keeps them enforced, so it's clearest as a unit. A one-off script to reshape a file will be read twice and deleted: plain procedures. And a system several people will extend for years is mostly units, because boundaries let people work in parallel.
Design Checklist
Questions to Ask of Any Problem
Here are questions worth asking of any new problem. What are the nouns, and do any of them have rules? A thing with states that must stay valid is a candidate for a unit of its own. Which data is touched from more than three places? That's where trouble accumulates, whichever style you use. What's most likely to change? Put a boundary around it, so the change stays local. And how long will this live, and how many people will touch it? Finally, can you explain each part in one sentence? If not, the parts are probably cut along the wrong lines. One more term: cohesion, how closely the contents of one part belong together. Coupling should be low, and cohesion high.
Key Takeaways
Verbs, Nouns, and Low Coupling
To summarize. Procedural design makes the parts verbs: operations around shared data. Object design makes them nouns: units that hold their own data and rules. Shared changeable data causes ripple effects. The real goal is low coupling and high cohesion. Procedures win for small, short-lived, single-person work. Objects win as programs, lifetimes and teams grow. And C++ lets you choose per part, not once for the whole program.
Think About It
Challenging the Object-Only Claim
Here's something to think about. A colleague says every program should be written in the object style, because it's more modern. Give two grounds on which to disagree.
About C++ Programming at UPI Study
C++ Programming (Computer Science 242) is a self-paced online course of 84 video lessons in 11 chapters, from your first program to decisions, loops, arrays, functions, classes, files, pointers and inheritance. 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 Every course with PRO →
Why take it here
Why students take C++ Programming with UPI Study
Where the credit goes
Universities that work with NCCRS
C++ Programming 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 UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks 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 Procedure-Driven vs. Object-Driven
What is the difference between procedural and object-oriented design in C++?
Who can change the data in a procedural design versus an object design?
What is a ripple effect in software design, and how do coupling and cohesion relate to it?
Should I use objects or plain functions in C++?
About the C++ Programming course
How many college credits is C++ Programming?
How much does C++ Programming cost and what is included?
Which universities accept UPI Study credits?
How long does C++ Programming take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in C++ Programming.
84 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →