"Object-oriented" refers to a world-view that identifies and describes "things". These "things" have attributes and behaviors. A system is built of "things" that communicate and coordinate. A specific "thing", a particular car, invoice, or receipt, is called an object. A description, attributes, and behaviors, of a general "thing", cars, invoices, or receipts, is called a class. We describe the attributes and behaviors of classes and then instantiate specific ones as objects. Objects interact, exchange data or messages, so as to update each other and otherwise coordinate.
A purely procedural approach uses only a sequence of instructions. We can choose which instructions to execute and can repeat sets of instructions. Between pure-procedural and object-oriented is the modular approach which is the use of subroutines and scope within procedures. While not truly object-oriented, its principles allow us to make the best use of languages that take a modular approach. An example is the C language. It is not object-oriented, but the principles can be applied to its modules and data structures. This improves our use of such languages.
Despite all of this, it is not a choice of procedural, modular, or object-oriented. Rather, those three represent an evolution. Procedural code is still used to write an object's behaviors. Classes are an expansion of the concepts behind modules. When employing object-oriented languages to their best effect, all three are used, with a solid object-oriented approach being the goal.
Review Traditional vs. Object-Oriented Approaches: Pay particular attention to Part 5, note the similarity between the project management described here and what was discussed earlier.
"Class" refers to a general description of something that gives it attributes and behaviors. For instance, a car may have doors. Each door may have a different color (attribute) and the doors may open and close (behavior). "Object" refers to a specific entity that exists within the universe of our application. For example, we may have a specific car that is assigned a unique attribute such as "license plate". There is no other car like that one. You can identify a particular car by a key attribute or by its position in a vector, an address location in memory.
There is an interesting case with classes in that they can inherit other classes. For instance, the car class may inherit a door class. With that capability, it is possible to describe a general-purpose door that has all the attributes and behaviors as every door. A particular type of car can inherit the general door and add to it. Thus, the classes making up the application's world can be built up from many other classes. But, beware of overdoing inheritance. Remember the modular nature of the object-oriented approach. You should be able to easily extract classes for reuse, just as one should be able to extract subroutines, functions, and structures from procedural languages.
The concept of classes can be extended through polymorphism, the ability of a class to behave differently under different circumstances. For instance, a class-animal may behave differently if it is inherited by class-human instead of by class-dog. It depends on what attributes and behaviors have been overridden by the inheriting class. Overriding basic operators is another example. Numbers may behave differently under such circumstances. Use such capabilities carefully since they increase the software's complexity. Increasing complexity does not make us appear smart. Rather "smart" is shown in maintainable and understandable systems that are produced within budget and schedule, and which satisfy long-term customer needs and wants.
Review Objects and Object-Oriented Programming: The first half is review, be sure you understand what is discussed in paragraph nine onward.
An essential aspect of object-oriented programming is that class descriptions are separate from associated objects, class instantiations. Especially with third-party libraries, we often do not have access to class descriptions, only to their interfaces. This enhances modularity and allows us to use the same description for multiple purposes. It also eases class maintenance and evolution since only one class description exists for all associated objects. Important too is that an object instantiates a class description as a completely independent entity. An important result is that the value of a class attribute exists only for that object and does not affect the attribute's value of any other object. Behaviors of a class affect only a particular instantiation, object, of that class.
Once an object is instantiated, its private behaviors and attributes cannot be accessed by anything outside that object, even by objects of the same class. It is possible to declare attributes and behaviors as public but that should be done with care. As systems become more complex, it is difficult to keep track of which other object, subroutine, or code component is modifying which objects at what time. This is especially true when multiple independent parallel or distributed processes are involved. Generally, it is best to not allow code from outside an object to directly modify anything within the object. By controlling access to class attributes and behaviors, we "encapsulate" those within the class description.
From a general description (class definition) we can create more specific descriptions. For instance, based on the description of a general ground-based vehicle, we can go on to describe trucks, cars, and buses. All would use (inherit) the description of a general ground-based vehicle. Or, we can extend the description of a general ground-based vehicle by adding a new behavior or attribute. These are very powerful approaches to design and programming if applied judiciously. They go well beyond pure-procedural or modular approaches since those do not take object-orientation to its fullest extent, although object-orientation does include procedural or modular concepts.
This vocabulary list includes the terms listed above that you will need to know to successfully complete the final exam.