Lesson 5

This lesson has shown you the benefits that OOP brings to a project and to a programmer.
You have learned how to:

1. Keep your analysis in the business world, using business words, with encapsulation of related strings and numbers into classes
2. Make teamwork more productive by separating classes that require specialized knowledge from those that do not.
3. Achieve reuse without instruction lists from the programmer who wrote the code you are reusing.
4. Compare the responsibilities of your classes with the overall project scope to ensure nothing's been forgotten.

The next module discusses classes and objects in more detail and illustrates how to create class and object diagrams.

To evolve object-oriented code, one must understand both the code structure in terms of classes, and the runtime structure in terms of abstraction of objects that are being created and the relation between those objects. To help with this understanding, static program analysis^[1] can extract heap abstractions such as object graphs. But the extracted graphs can become too large if they do not sufficiently abstract objects, or too imprecise if they abstract objects excessively to the point of being similar to a class diagram that shows one box for a class to represent all the instances of that class. One previously proposed solution uses both annotations and abstract interpretation to extract a global, hierarchical, abstract object graph that conveys both abstraction and design intent, but can still be related to the code structure. Here we define metrics that relate nodes and edges in the object graph to elements in the code structure to measure how they differ, and if the differences are indicative of language or design features such as 1) encapsulation, 2) polymorphism and 3) inheritance. We compute the metrics across eight systems totaling over 100 KLOC, and show a statistically significant difference between the code and the object graph. In several cases, the magnitude of this difference is large.

In object-oriented (OO) programming, an application consists of a series of objects that ask services from each other. Each object is an instance of a class that contains a blueprint description of all the object's characteristics. Contrary to procedural programming, an object bundles both its data (which determines its state) and its procedures (which determines its behavior) in a coherent way. An example of this could be a student object having data elements such as ID, name, date of birth, email address, and so on, and procedures such as registerForCourse, isPassed, and so on. A key difference between OO and procedural programming is that OO uses local data stored in objects, whereas procedural programming uses global shared data that the various procedures can access directly. This has substantial implications from a maintenance viewpoint. Imagine that you want to change a particular data element (rename it or remove it). In a procedural programming environment, you would have to look up all procedures that make use of the data element and adapt them accordingly. For huge programs, this can be a very tedious maintenance exercise.
When you are using an OO programming paradigm, you only need to change the data element in the object's definition and the other objects can keep on interacting with it like they did before, minimizing the maintenance. OO programming is the most popular programming paradigm currently in use. Some examples of object-oriented programming languages are Eiffel, Smalltalk, C++, and Java.

Click the Quiz link below to test your knowledge of the advantages of OOP.
Object Oriented - Quiz

[1] Static program analysis: In this type of analysis of computer software, analysis is performed without actually executing programs, in contrast with dynamic analysis, where analysis is performed on programs while they are executing.