What’s the big deal with OO?

Object-oriented techniques using classes and virtual functions are an important way to develop large, complex software applications and systems. So are generic programming techniques using templates. Both are important ways to express polymorphism – at run time and at compile time, respectively. And they work great together in C++.

There are lots of definitions of “object oriented”, “object-oriented programming”, and “object-oriented programming languages”. For a longish explanation of what Stroustrup thinks of as “object oriented”, read Why C++ isn’t just an object-oriented programming language. That said, object-oriented programming is a style of programming originating with Simula (about 40 years ago!) relying on encapsulation, inheritance, and polymorphism. In the context of C++ (and of many other languages with their roots in Simula), it means programming using class hierarchies and virtual functions to allow manipulation of objects of a variety of types through well-defined interfaces and to allow a program to be extended incrementally through derivation.

See whats so great about classes for an idea about what’s great about “plain classes”. The point about arranging classes into a class hierarchy is to express hierarchical relationships among classes and to use those relationships to simplify code.

To really understand OOP, look for some examples. For example, you might have two (or more) device drivers with a common interface:

class Driver { // common driver interface public: virtual int read(char* p, int n) = 0; // read max n characters from device to p // return the number of characters read virtual bool reset() = 0; // reset device virtual Status check() = 0; // read status };

This Driver is simply an interface. It is defined with no data members and a set of pure virtual functions. A Driver can be used through this interface and many different kinds of drivers can implement this interface:

class Driver1 : public Driver { // a driver public: Driver1(Register); // constructor int read(char*, int n) override; bool reset() override; Status check() override; private: // implementation details, including representation }; class Driver2 : public Driver { // another driver public: Driver2(Register); int read(char*, int n) override; bool reset() override; Status check() override; private: // implementation details, including representation };

Note that these drivers hold data (state) and objects of them can be created. They implement the functions defined in Driver. We can imagine a driver being used like this:

void f(Driver& d) // use driver { Status old_status = d.check(); // ... d.reset(); char buf[512]; int x = d.read(buf,512); // ... }

The key point here is that f() doesn’t need to know which kind of driver it uses; all it needs to know is that it is passed a Driver; that is, an interface to many different kinds of drivers. We could invoke f() like this:

void g() { Driver1 d1(Register(0xf00)); // create a Driver1 for device // with device register at address 0xf00 Driver2 d2(Register(0xa00)); // create a Driver2 for device // with device register at address 0xa00 // ... int dev; cin >> dev; if (dev==1) f(d1); // use d1 else f(d2); // use d2 // ... }

Note that when f() uses a Driver the right kind of operations are implicitly chosen at run time. For example, when f() is passed d1, d.read() uses Driver1::read(), whereas when f() is passed d2, d.read() uses Driver2::read(). This is sometimes called run-time dispatch or dynamic dispatch. In this case there is no way that f() could know the kind of device it is called with because we choose it based on an input.

Please note that object-oriented programming is not a panacea. “OOP” does not simply mean “good” – if there are no inherent hierarchical relationships among the fundamental concepts in your problem then no amount of hierarchy and virtual functions will improve your code. The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies – the main weakness of OOP is that too many people try to force too many problems into a hierarchical mold. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).

If you’re still wondering “why OO?”, consider also business reasons:

The software industry is succeeding at automating many of life’s functions that used to be manual. In addition, software is improving the flexibility of devices that were previously automated, for example, transforming the internal implementation of many previously existing devices from mechanical to software (clocks, automobile ignition systems, etc.) or from being controlled by electrical circuitry to software (TVs, kitchen appliances, etc.). And, of course, software is integrated into every aspect of our daily business lives — originally software was limited to Accounting and Finance, but it is now embedded in Operations, Marketing, Sales, and Management — software is nearly everywhere.

This incredible success has constantly stressed the ability of the software development organizations to keep up. As an industry, software development has continuously failed to meet the demands for large, complex software systems. Yes, this failure is actually due to the success of software’s ability to bring perceived value — it is actually caused because demand is greater than our ability to satisfy that demand. And while it is possible for us software people to sit around and pat ourselves on the back for that demand, innovators and thought leaders in this and every other discipline are marked by one undeniable characteristic: they/we are not satisfied. As an industry, we must do better. A lot better. Uber better.

Our past successes have propelled users to ask for more. We created a market hunger that Structured Analysis, Design and Programming techniques have not been able to satisfy. This required us to create a better paradigm. Several, in fact.

C++ supports OO programming. C++ can also be used as a traditional, imperative programming language (“as a better C”) or using the generic programming approach. Naturally each of these approaches has its pros and cons; don’t expect the benefits of one technique while using another. (Most common case of misunderstanding: don’t expect to get the benefits of object-oriented programming if you’re using C++ as a better C.)

C++ also supports the generic programming approach. And most recently C++ is starting to support (as opposed to merely allow) the functional programming approach. The best programmers are able to decide which approach fits best in which situation, rather than trying to shove a single approach (“my favorite approach”) at every problem everywhere in every industry irrespective of the business context or the sponsor’s goals.

Most importantly, sometimes the best solution is achieved by using a combination of features from Object-Oriented, Generic and Functional programming styles, whereas trying to restrict oneself to one particular approach may lead to a suboptimal solution.