Back To Basics

What is OOP?

Most people think of their business systems in terms of the interactions of people, institutions and systems. When describing a system, they often speak in terms of these interactions between entities. For example, they may describe how a customer communicates order information to a salesperson that inputs this information into an Order Processing program. Describing entities and defining how those entities interact with one another maps very well to Object Oriented Programming (OOP). OOP is a programming paradigm that focuses on the objects in a software system and the messages passed between those objects.

Object Oriented Programming is not a new concept. The ideas behind it were first published in the 1960s and the SmallTalk language, developed in the 1970s, formalized many of the programming constructs used in this paradigm. However, OOP gained popularity in the 1990’s with the increased use of the C++ and the last ten years have seen an explosion in object-oriented languages C#, Visual Basic.Net and Java.

In earlier programming models, a program was viewed as a set of methods or subroutines. A main method would call one or more subroutines that might each in turn call other subroutines. Each subroutine would complete its task and return control to the method that called it. Using this approach, developers viewed their programs as a set of tasks. These tasks became central to their application design.

Managing Complex Systems

It was difficult to manage complexity in this task-oriented approach to programming.

For example, one couldn’t be certain that a subroutine would not substantially change variables, files and other parts of the environment. The only way to know for sure was to examine that subroutine in detail to learn how it worked. In fact, you would need to also examine any subroutines called by that subroutine, to verify that they didn’t cause any unexpected side effects.

Another complexity arises because there tends to be a tight coupling between the subroutines. Changes to a subroutine often require changes to any routine that called it, making maintenance difficult.

Often in such systems, you find code duplicated in multiple places. Making a fundamental change to how a rule is implemented requires changing code several times – another maintenance difficulty that adds to complexity.

The Development process itself adds to the complexity of writing software. On most projects, we need to consider how to divide development tasks among team members; merge this code together; manage code deployment; test code modules independently and together; deploy updates to our application; and fix errors as they are found. The entire process can be quite complex, particularly if all our modules are tightly bound together.

Finally, we cannot ignore the fact that many of the problems we are trying to solve are complex. This complexity is often our motivation to automate these problems in the first place. Anything we can do to mitigate that complexity – such as splitting a problem into manageable components – will assist us in building a solution.

OOP attempts to address these challenges by focusing on objects instead of tasks. The whole goal of OOP is to manage complexity. This is done by splitting a complex system into manageable, independent pieces and only exposing enough of each piece to allow other objects to work with it. Much of the complexity of the object can be hidden from the outside world, making the system as a whole easier to understand.

The following basic principles help to accomplish OOP’s goal of managing complexity.

  • Inheritance
  • Abstraction
  • Encapsulation
  • Polymorphism
  • Decoupling

The above concepts are interrelated in that some are used to accomplish others. In a later article, we will dive into more detail about each.

Before we can do that, it’s important to understand the basics of objects before you can grasp Object Oriented Programming.

Next: Intro to OOP, Part 2: Understanding Objects 


Thanks to Chris Woodruff, who contributed to this article.