Overview of the Object-Oriented Paradigm

Section 0: Module Objectives or Competencies

Section 1: Concepts of the Object-Oriented Paradigm

The fundamental idea behind object-oriented design is to combine both data and the functions that operate on that data into a single unit called an object.

• Instead of viewing the world as a set of processes, it instead views the world as a collection of entities that are characterized by certain behaviors.
• Object-oriented designs are better able to more accurately model the real world than procedural approaches.

Quick Overview

Video: Classes and Objects

Classes

Although we refer to this as the object-oriented paradigm, something called a class provides the basic building block.

• Before you actually "create an object," you design the template for the object. This template is called a "class."
• All code that the object does, and properties of the object are placed inside the class.
• Thus, a class defines the set of shared attributes and behaviors found in each object in the class.
• A class is the blueprint from which individual objects are created.

Example: consider a student.

• Before we describe details about a specific student, like David, we need to decide what characteristics are shared by all generic students. So here is our generic student. It looks pretty plain, but happy!
• 
• Most students share some common characteristics like student number, name, permanent address, local address, phone, email, major, GPA, etc. These are referred to as attributes, or instance variables.
• They also have certain things that they can all do, like enroll in classes, drop classes, change major, etc. These are generally called behaviors.
• The specification for a rudimentary student class might look like this:
• 
• Now that we know a little bit more about "a student" let's make our image a little more specific.
• 
• So we see that classes have both attributes (such as the student number, name, and major) and behaviors (such as "enroll in class" (called "addClass") and "change major" (called "setMajor")).
• Because classes contain generic details, they serve as patterns, or cookie cutters, for the more detailed objects.

Objects

An object is a specific, and therefore more detailed, instance of a class.

Let's go back to our student example.

• To create a specific object from a class we need to know a few more details. In fact, we need to provide values for each of the instance variables.
• Here is an example that describes David, our favorite fictional student:
• 
• Notice that we now have specific details about David that distinguish him from other students. Our image can be more specific as well:
• 

Instantiation

Classes must be defined by the designer before objects can be created from the class.

• The term instantiation is used when an object is created from a class.
• For example, a system could instantiate David as an object from the class Student.

Just as an instance of a primitive data type is called a variable, an instance of a class is called an object.

There may be many objects that belong to a class, just as there may be many variables of a primitive data type.

Placing data and functions together into a single entity is the central idea of the object-oriented approach.

Section 2: Terminology

The OO approach is generally characterized by four distinguishing features – abstraction, polymorphism, inheritance, and encapsulation (sometimes referred to collectively as A-PIE).

• abstraction
• encapsulation
• inheritance
• polymorphism

Why aren't they listed in A-PIE order? The A-PIE order is used to help you remember the features, but in design you will encounter them in the order presented in the list.

Quick Overview

Video: Basics of OO

Abstraction

Abstraction requires the designer to ignore irrelevant features, properties, or functions while emphasizing those that are relevant to the given project.

Consider again our student example:

• While it would be easy to obtain a student's hair color, eye color, height, and weight when they register for classes, those details are not relevant to an enrollment system.
• However, attributes like major and GPA are critical.
• Note that in other scenarios, like compiling a list of students interested in participating in an intramural basketball league, attributes like height suddenly become relevant.
  • This indicates that context dictates what is and is not abstracted.

Encapsulation

Encapsulation is the act of grouping into a single object both data and the operations that affect that data.

• Directly related to this is the requirement that data stored within an object can only be accessed by methods defined by the object's class.
• In other words, outside processes are prohibited from altering the nature of the object.

Example: David the student requests that his major be changed to INFO.  The enrollment system sends a "Change Major" message to the David object (class Student). The David object has a behavior (also called a "method") called setMajor, that reacts to this message by changing its own object's 'major' attribute to 'INFO'.

Encapsulation is significant because

• it makes it easier to build objects that are very reliable and consistent because they have complete control over their own attributes, and
• it makes system maintenance and change much easier because if the values of an object's attributes are incorrectly changed, then the object changed those values itself.

Inheritance

Inheritance is the process of creating new classes (derived classes) from existing classes (base classes).

A derived class can be created in such a way that it will inherit all of the attributes and behaviors of the base class.

Example: Person and Student class

• Assume that we created a generic Person class with the following class members:
  
• Since students also have ids, names, addresses, phone numbers, and email addresses, instead of creating a Student class from scratch we can reuse the Person class that we already created and inherit its properties in the Student class.
• The resulting student class would look like...
  
• The student class still has name, address, etc., but they do not appear explicitly in the class specification because they are inherited from the Person class.
• When we get to the section on UML, you'll see that inheritance is represented like this:
  

A derived class shares all the characteristics of a base class, but can add new characteristics as well. A derived class is not limited to the inherited attributes and behaviors.

• In our example the Student class added major and GPA, as well as their associated behaviors.

Inheritance reduces development labor by reusing existing objects.

• The developer only needs to declare that the Student class inherits from the Person class and then provide any additional details about new attributes or behaviors.
• All of the existing attributes and behaviors of the Person class are automatically and implicitly part of the Student class and require no additional labor.

Polymorphism

Polymorphism refers to the ability to perform the same operation on different types of objects, each one implementing that operation in a way appropriate to them.

Polymorphism enables a message to have different effects depending on exactly what class of object receives the message.

Example: setAddress in the Person and Student classes

• Both the Person and the Student classes have a setAddress method, since the Student class inherits its behaviors from the Person class.
  • The Person class might react to a setAddress directive by setting its address attribute.
  • The Student class has both an address (which represents their permanent address) and a local address (localAddress). Which address is more likely to change more often? Probably their local address since they are attending college. Therefore the method setAddress might be better used to change a Student object's local address rather than the address attribute. Therefore the Student class might react to a setAddress directive by setting its local address attribute.
  • Objects of both the Person class and the Student class respond to a setAddress directive, but they do so in a slightly different manner.

Thus, when multiple classes inherit both attributes and behaviors, there can be cases where the behavior of a derived class might be different from that of its base class or its sibling derived classes.

The "Rachel" student object can be directed to change its address without knowing if Rachel is an object that belongs to the Student or the Person class.

Here is another example if polymorphism isn't clear.

Related concepts

Instances

An object has the same relationship to a class that a variable has to a data type.

An object is said to be an instance of a class.

Methods

Methods are member functions that are included within a class in order to implement a specific behavior that objects of that class are capable of performing.

In order for an object to perform an action, one of its methods must be invoked.

If a class does not include a method for a particular action, then objects of that class cannot perform that action.

Extensibility

Extensibility refers to the creation of new data types from existing data types.

Inheritance is a form of extensibility.

Reusability

Once a class has been written, created, and debugged, it can be used in multiple systems.

Reusability can be utilized in conjunction with inheritance to create derived classes from a base class.

Information Hiding

Information hiding is the technique of concealing implementation details within the objects themselves, while the interface remains visible.

Data is concealed within a class, so that it cannot be accessed mistakenly by functions outside the class.

Section 3: Systems of Objects

The following is adapted from Basic Object-Oriented Concepts.

In constructing object-oriented models and object-oriented applications, one quickly finds that single classes and single instances are not enough.

• You need some way of creating and dealing with large objects.
• A system of objects is defined as two or more interacting or interrelated, non-nested objects.

Systems of interacting objects are collections of items that support a single, large, coherent, object-oriented concept, and in which there must be a direct or indirect physical connection between any two arbitrary objects within the collection.

Systems of interacting objects resemble applications.

• For example, suppose that we wanted to construct an object-oriented application that controlled the elevators in a particular building.
  • We would assemble elevators, buttons, lamps, panels, and other objects into a working application that would control the elevators.
  • Such an application would be viewed as a highly cohesive whole, i.e., a system of interacting objects.

Class Interactions

So a software system is often made of various classes.

Once the various classes have been specified, the designer has to determine how those classes interact with each other.

• Those interactions are generally specified using UML diagrams.
• Here is an overview of UML concepts.

Here is an example UML diagram from this old assignment:

UML Diagram

Section 4: Summary

One benefit of the object-oriented approach is the close correspondence between the real-world things being modeled by the system and the objects in the system.

This makes it easy to conceptualize a problem. You figure out what parts of the system can be most usefully represented as objects, and then put all the data and methods connected with that object into the class specification.

In some situations it may not be obvious what parts of a real-life situation should be made into objects because there are no hard and fast rules. Often you proceed by trial and error. You break the problem into objects in one way and write trial class specifiers for these objects. If the classes seem to match reality in a useful way, you continue. If they don't, you start over, selecting different entities to be classes. The more experience you have with OOP, the easier it will be to break a system into classes.