Object-Oriented Programming

Preface: These notes are not meant to be a complete presentation of the material. Instead, they are designed as a very brief outline of topics/terminology to be discussed in class. Note that a few preliminaries about object-orientation were discussed in Section 3.3 of the text.

Cornerstones of Computing: Data and Operations

Data (use of memory)

built-in vs. user-defined data types

Operations (use of CPU)

built-in vs. user-defined operations/functions;
flow of control;
higher-level algorithms

Object-Oriented Programming

Thoughtful pairing of data/operations.

class: (e.g., Canvas, Rectangle, Color)

object/instance: a member of a class. Created through the process of instantiation, by calling the class constructor

trunk = Rectangle(30, 70)

There can be many instances of a class. Each instance has its own state information (via "data members")

What the class does is defines the internal representation for storing the state information, and the algorithms used to implement the external behaviors of its instances.

Methods

In object-oriented terminology, we tend to use the following as synonyms:
operation, action, behavior, member function, method.
(Our prefered terminology is method.)

paper.setTitle('My Zoo')
body.move(200, 100)
paper.add(body)

Terminology: calling/invoking the method, the caller and callee, the method name, parameters.

Note: the calling syntax for a method is different from the original construction, such as Rectangle(30, 70)

Note: object-oriented syntax is different from traditional function calling, such as sleep(0.5). Note that there is no callee (and no state information) when using traditional functions.

Note: parentheses are required, even when zero parameters are sent, as in, paper.close(). Omitting those parenthesis is a common "gotcha"

Syntax/Semantics

The syntax of a method is the formal language used for calling the method (e.g., body.move(200, 100)). We typically refer to a description of the syntax as the signature of the method.

The semantics of a method are the effect of such a call. Typical considerations:

• How might a method call affect the state of the callee?
• How might a method call affect the state of other objects?
• What information is returned by the call?
  We call such information the return value (in Python, it is None by default)

Methods that may change the state of the callee are known as mutators. Methods that cannot change the state are known as accessors (those are typically used to return information to the caller).

Data Members and Encapsulation

We noted that each instance of a class has its own state information. That must be stored in memory in some way. This is typically done by managing one or more attributes (aka data members) for each object.

A key principle of object-oriented program is known as encapsulation. All interactions with objects should be through calling methods, and outside users should never need to directly access the internal attributes. The responsibility for maintaining attributes is left to the designer of the class. This creates a distinction between the public interface and private implementation.

For example, although our cs1graphics.Rectangle class supports behaviors getWidth, setWidth, getHeight, and setHeight. However, internally we do not explicitly store a "width" or "height" attribute for a rectangle! Those are actually based on computing measures of a transformation matrix. But you don't need to know this to be a user of the graphics package and the Rectangle class.

Complex Projects

In large object-oriented systems, there will be many instances of many different classes, all interacting through a sequence of method calls.

Can portray such interactions with sequence diagrams (one was given as Figure 3.4 on page 31 of Chapter 3).

Beauty of OOP and encapsulation is that it makes it much easier to develop, maintain, adapt, and reuse software. Each class has its well-defined responsibilities. Higher-level functionality is based on interactions.

• Development: as long as there is agreement on the public interface for a class, one programmer can start writing code that uses the class, even while another program is implementing the class

• Debugging: can often test individual classes and locate problems before intergrating the whole system. Even if a bug appears in the full system, it should be easier to track down which class contains the error.

• Maintenance: Developers can reimplement the internals of a class (either to fix bugs, or to improve performance), and so long as they do not change the public interface, client code need not be changed.

• Reusability: Classes with general responsibilities can often be reused across many different projects.

Class Hierarchies and Inheritance

This is an advanced OOP technique that allows one or more subclasses to be developed as extensions of an existing base class. By taking advantage of commonality among groups of classes, inheritance promotes greater code reuse. Alternate terminology: subclass aka child class; base class aka parent class

We will revisit this technique around mid-semester, but you have already seen the use of inheritance in our cs1graphics package (e.g., Drawable, Shape, FillableShape, Circle, Rectangle, Text). The use of inheritance greatly helped us in implementing the graphics pacakge. It also makes it a bit easier for users of the library because there is a lot of common syntax shared by different classes (e.g., setFillColor)