Object-Oriented Programming

OO has strong historical roots in other paradigms and practices. It came about to address problems commonly grouped together as the “software crisis”.

This metaphor requires a multi-threaded OO model – interesting, but a bit more complicated to start with.

This demonstration uses a very simple ATM system to contrast the execution of a structure and an OO program.

A standard naming scheme for classes, objects, instance variables, and methods is important. Here are two alternatives.

The object model has many facets. Here are the ones you'll eventually have to understand to be mature OO developers.

An abstraction is a simplified description of a system which captures the essential elements of that system (from the perspective of the needs of the…

Messaging is how work gets done in an OO system. Understanding messaging is a key part of being able to visualize how an OO program executes.

We encapsulate the details of a class inside its private part so that it is impossible (and not just suggested) for any of the class's clients to know about or depend upon these details.

We group our abstractions (classes) into a hierarchy to keep them organized (inheritance structure).

In OO languages, type is a synonym for class, at least as a first cut. In fact, class and type are quite distinct.

OO helps us with the complex issues of concurrency in the same way that is helps us with our "programming in the large" problems.

The micro process is iterative and also emphasizes the interface and relationships between classes and objects over the implementation of specific methods.

Behavior analysis, domain analysis, use-case analysis (storyboarding), pattern scavenging, and classical analysis.

Analysis is expensive in time and money, and takes a lot of skill, both in the domain of the problem, and in the OO domain.

Unified Modeling Language is a "method for specifying, visualizing, and documenting the artifacts of an object-oriented system under development."

CRC cards are a simple representation of the classes in an OO system. They are often a good way to get started when facing a new project.

We're going to look at the way we define the relationships between classes so we know how objects can relate to each other.

UML has a very specific use of the terms aggregation and composition, though this is not necessarily consistent with OO authors.

The classes toward the top of an inheritance hierarchy tend to be abstract classes that won't have any objects instantiated from them.

Using is not the same as aggregation, since the class being used doesn't satisfy the whole/part question. The used class exists to help the first class.

The potential confusion for people new to OO is that instantiation is what happens to create an object, yet this is a class-to-class relationship, no objects are involved.

For OO languages polymorphism is tied up with substitutability. We design methods and we write client code that can operate on a set of types.

An overview of terms and ideas covered: Objects, Classes, Encapsulation, Inheritance, Messaging, Identity, Polymorphism, and Type.

Object oriented analysis, design, and implementation are an iterative process. It's impossible to fully design the classes of an OO system at the outset.