Skip to Content

PL: Object Orientation

Posted on 6 mins read

From old CS 471 notes…

Object Orientation (Chs 11 & 12)

Abstraction

Abstraction is one of the fundamental concepts in Computer Science.

Perhaps even in all of human endeavors.

It lets us deal with more complex things than we can individually understand.

Traditional imperative (and other) programming languages have offered separate data abstraction and control (process) abstraction.

Object Oriented ideas unify the two.

Abstract Data Types

Main idea #1: A data type is not just the data representation but also the operations that are allowed on the data. An ADT definition defines data and operations.

Main idea #2: Many concepts that are created when programming can be viewed as abstract data types. It’s not just for built-in types and a few data structures.

E.g., a “customer” idea in a business program can be an ADT.

Signed integers as an ADT:

  • Abstract data: can hold integer values from NEGMAXINT to POSMAXINT
  • Concrete data: N bytes storage, Two’s Complement representation
  • Abstract operations: all typical integer math operations.
  • Concrete operations: machine arithmetic instructions, plus library routines if needed
  • Slight breakdown in abstraction: bitwise operations and shifts

Object Oriented Ideas

Data and control abstraction should be unified.

Users should be able to create their own ADT’s.

Since built in types are related, so user types should be (able to be) related.

The big three OO features: Encapsulation, Inheritance, Polymorphism

For user-defined types, OO chose the term class, partly because some languages already used “type” to refer simply to data abstraction (e.g., “typedef” in C).

An instance of a user defined type is an object.

Most languages do not treat variables of built-in types as true objects, but they do this only for efficiency; in a purely idealistic sense, there should be no difference between variables of user defined types and variables of built-in types.

Encapsulation

Two ideas here: packaging and hiding.

Data and control should be able to be packaged together: classes allow both member fields and member methods.

Some members (data and/or methods) should be accessible only from within, and thus hidden from the external world (program).

Typical OO hiding:

  • public: not hidden, member is visible externally;
  • private: completely hidden, member is visible only within class;
  • protected: mostly hidden, member is visible within class and within sub-classes;
  • package: member is visible to other classes in package.

Good OO programming demands that data members be made private!

Yet, getters and setters (e.g., getX() and setX(val)) are clumsy. Some say “evil”.

A third abstraction beyond data members and method members: properties

A property has two faces:

  • externally it looks like a data member, and you can use the nice assignment syntax to update it, and refer to it like a data member;
  • but internally you implement it with getter and setter methods.

See Wikipedia:property.

Some languages with properties: Visual Basic, C#, Python, PHP, (JavaBeans), etc.

Inheritance

Just as built-in types are related, user defined types can be related through inheritance.

Inheritance is (or should always be) an is-a relation. If type B inherits from A, then an object of type B is an object of type A.

That is, anywhere an object of A can be used, so can an object of B.

But not vice versa.

A is a parent class or base class or superclass; B is a derived class or subclass.

Inherit usually implies the automatic addition of all of a parent class' data and methods to the subclass.

Design issues for OO languages:

  • Interface or implementation inheritance?
  • Single or multiple inheritance?
  • Single inheritance tree or multiple trees?

Interface inheritance only inherits the interface definition of methods, not the implementations; each class must implement its own versions of the interface declarations.

Implementation inheritance does inherits the implementations of methods in parent classes, although a class is generally able to override the parent implementation with its own.

Single inheritance means that a class can have only one parent class (but a parent class can have more than one subclass).

Multiple inheritance means that a class can have more than one parent class.

Single inheritance tree means that all classes are ultimately derived from a single root base class.

Multiple inheritance trees means that there is no single root base class; classes can be related to each other (trees), but there is a disjoint forest of inheritance trees.

C++: Implementation inheritance, can support interface inheritance with abstract methods; multiple inheritance; multiple inheritance trees.

Java: Implementation and interface inheritance (extends and implements); single implementation inheritance, multiple interface inheritance; single inheritance tree (root class: Object).

Note: Inherited C++ methods are not automatically overrideable; they must be declared virtual in order to be able to be redefined in a subclass.

Abstract base class

In OO, a class is abstract if no objects of it are ever created.

Example: there is no such thing as a concrete “mammal”; there are only animals of type squirrel, cat, dog, deer, etc., which are mammals (the is-a relationship). Mammal is an abstract class.

An abstract class must be subclassed to be used properly. Objects of the subclasses are instantiated.

Typically, this is support in OOP languages for defining a class to have some method M, but not providing an implementation of the method.

Subclasses are forced to provide an implementation of the method.

Java supports abstract classes and methods with the keyword abstract. A declaration of an abstract method does not provide a body for the method.

In C++, an abstract method is declared virtual and with a body “=0;”.

Java example: You cannot create objects of interfaces or abstract classes, but you can declare variables of such!

Question: Where is this most useful?

Polymorphism

From the Greek “poly” meaning “many”, and “morph” meaning “shape”.

Polymorphism allows some thing to be used in a variety of forms.

Already have seen:

  • Ad-hoc polymorphism: operator and function overloading, where one operator symbol or one function name ends up with different meanings depending on the context;
  • Parametric polymorphism: C++ templates and Java generics; this is where a template/generic definition takes on different meanings depending on the type parameter given to it at usage-declaration time;

Now in relation to OO ideas, we have subtyping polymorphism.

This is where an object of a subclass can be substituted for and used in any code that expects an object of a superclass.

Packages

Most OO languages have some form of hierarchical packaging on top of the basic class mechanism.

C++ has namespaces, Java has packages, C# has assemblies.

Typically must provide fully qualified names to refer to entities in other packages, or import the names into your own code space so that you can use them directly.

In regards to encapsulation, Java rules are that a class member with no access modifiers has “package scope”, that is it is visible to other classes in the same package. The access modifier protected also has package scope.