Scoping Out OO

April 22, 2014 — Posted by Scott Bain

I will assume that most people reading this blog need no convincing as to the value of object-oriented technologies and methods.  This is also largely true of the students who attend our design and testing courses; they are there because they want to learn to use OO better not because they have doubts about it.

That said, now and again I run into some people who need convincing.  Lately this has been happening more than usual.  They generally approach me at lunch, or at a break, or at the end of the day when most people have left and I am packing up my computer and such.  Someone will come up and start asking questions about the “why” of OO, what the value is, why we should bother with it.  Often they will also have concerns such as “the code gets spread out all over the place, making it hard to read” or “the stack depth concerns me, in terms of performance, with all these methods calling each other,” things like that.

One thing I learned early in my career as a teacher is that you have to come to understand the way someone will interpret your answer before you know the right way to approach an explanation.  Al calls this “their listening”, and it is very important.  What they hear is what gets communicated, not what you say.  Because of this I have multiple ways of approaching the argument for OO and lately I have had a lot of success with one particular line of reasoning.  I thought some of you might find this useful if you find yourself in a position of defending objects and OO to someone who does not yet see the value.

Imagine you were the greatest programmer you could possibly be, with the most skill, accuracy, wisdom, etc… that a person can possibly possess.  You would still write the occasional bug, would you not?  All humans are fallible even at their utmost level of skill.  But if you were really amazingly good maybe that would happen only once in a thousand lines of code, or maybe less often even than that.  Pick whatever number you like.

Of all the different kinds of bugs we write how many of them are really bad?  Most bugs are trivial, easy to fix once you find them (finding is usually the hard part if you think about it), and not really of much impact.  They are annoying but not serious.  But every so often a bug is really bad… causes terrible damage to the business or to people’s lives, is really hard to find and to fix, and hard to keep from recurring.  These “killer” bugs are quite rare; again, maybe one in a thousand or even less than that.  Pick whatever number you like.

Take the two numbers and multiply them together.  You have determined the size of a program that is guaranteed to have a killer bug and that is under the most ideal conditions imaginable.   Even the most died-in-the wool procedural person will admit that the larger a program gets the harder and more dangerous it is to work with.

By “a program”, however, what we really mean is “a scope”.  In procedural systems scope tends to be quite large and so we can theoretically get to the size that will certainly have serious issues.  What we need is to create isolated sections of code so that the scope basically never gets that large. 

This is nothing new of course.  In C we had two ways of creating a separate scope: functions, which have temporary variables that cannot be effected from outside the function, and structs, which keep data elements together (like the fields of an address) as they are copied from one place to another and so forth.

I was a procedural programmer for many years (I’m older than objects by quite a stretch).  When I first heard of the object or class, and I mused about what it was, I thought: “Hm.  I guess that’s like a struct except you also put functions into it and it is passed by reference rather than passed by copy.  Oh, and some of the data elements and some of the functions can be declared private.”

Well mechanically that is what a class is.  But the “private” part means that it can create a truly isolated scope – nothing outside can affect the private members of a class.  Inside the object we are basically in the standard situation; everything is visible to everything else except for temporary method variables.  An object is essentially a program and if a large system is comprised of a set of these “small scopes” then we never see any one of them get large enough that we run into the problematic mathematics of human error.

This is certainly not the only argument in favor of OO, maybe not even the most important one, but for some of my skeptical students this is a good starting point for the conversation.  Once they see any value in objects it can open the door for the elaboration that leads to the rest of the paradigm.

The other advantage of arguments like this, in terms of their persuasive power, is that they respect the existing understanding of the listener.  People can hear things much better if they do not feel they are being condescended to.  This is a major aspect of being an effective teacher or leader.


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban