Object-Oriented Programming

Object-Oriented Programming, often known by its acronym, OOP, is a term used more than it is understood . However, understanding OOP principles is important, since OOP really is the next step. Indeed, the previous chapters have given you the foundation to learn OOP.

I am not going to attempt to cover the entire subject of OOP in this chapter; entire books are written about OOP. Indeed, one of the companion books in the Demystified series to which this book belongs is Object-Oriented Programming Demystified. Nevertheless, let me try to briefly describe OOP.

While game programs are fun, the usual purpose of a program is to provide a solution to real-world tasks , which involve persons, places, things, or concepts. Programs use objects to represent a real-world person, place, thing, or concept.

Objects generally are abstractions, simplifying the real-world person, place, thing, or concept they represent. Just as you dont need to know how an internal combustion engine works to drive a car, you dont need to understand the inner workings of the object to know how to use it.

For example, as recently as the last chapter, we used objects, specifically the file stream objects, fstream, ofstream , and ifstream . We did not need to understand the inner workings of these objects, as detailed in the fstream standard library, to use them to open , read from, write to, and close files.

Objects are not limited to something as abstract as a file stream object, however. You are a person object. This book is a book object. The car you drive is a car object. A character in a game also is an object. The number and variety of possible objects is limited only by the programmers imagination and creativity.

Real-world objects also have relationships with other real-world objects. These relationships are either an is a relationship or a has a relationship.

An example of an is a relationship is that a teacher is a person. Some of my students have questioned this in respect to certain teachers , but then we call a truce after I remind them that a student also is a person, even though there are a few whom Ive had my doubts about.

An is a relationship is important because if you already have created a person class, when you write the teacher class you dont need to write code for those attributes that a teacher has in common with all persons, such as a name , birthday, height, weight and so forth. Rather, the teacher class can inherit those attributes from the person class, so you only need to write code for those attributes that a teacher has in addition to, or different than, all persons generally, such as tenure status, a higher education level, and so on.

This ability of one class to inherit from another is called, naturally enough, inheritance. Inheritance enables you to reuse existing code, such as the person class, when creating classes that represent more specialized objects, like teachers.

An example of a has a relationship is that a car has an engine. This type of relationship also is referred to as composition or, the term I will use, containership. Containership also enables you to reuse existing code, such as the engine class, when creating classes that represent the containing object, like cars .

Code reusability makes application development faster since you dont have to reinvent the wheel. Additionally, the applications you develop are less buggy since the code you are reusing already has been tested (hopefully).

Since structures and classes are heavily used in OOP, lets discuss them now.