Introduction to Object Oriented Programming

Why do we model?

In Object Oriented Programming we are trying to model either real world entities or processes and represent them in software. There are compelling reasons why we model:

A model is a simplification of reality. We model because we cannot comprehend the complexity of a system in its entirety.
We model to visualize, specify, construct, and document the structure and behavior of a system's architecture.
A model is a complete description of a system from a particular perspective.

Principles of Modeling

The model that we create is dependent on the problem that we are trying to solve and the entities in the scope of the problem.

The choice of what models to create has a profound influence on how the problem is attacked and how a solution is shaped.
Every model maybe expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.

Basic Principles of Object Orientation

Abstraction: the most important or essential aspects of something while ignoring the less important details. Abstraction is dependent on perspective - what is important in one context may not be in another. We model our problem domain using abstractions.
Encapsulation: physical localization of features into a single blackbox abstraction that hides their implementation behind a public interface. "Information hiding" is a corollary concept that indicates data fields are hidden from the user but the functionalities as implemented through functions are exposed.
Inheritance: organization of abstractions according to some order (e.g. complexity, responsibility, etc.).
Polymorphism: substitute variables or objects of one type with variables or objects of another type. Polymorphism gives us the ability to switch components without loss of functionality.

Basic Concepts of Object Orientation

Object
Class
Attribute
Operation (Function)
Polymorphism

What is an Object?

An Object represents an entity either physical (box), conceptual (chemical process), or software (list).

An Object is a concept, an abstraction, a thing with sharp boundaries and meaning for an application. It has

Identity - a name
State - determined by the values of its attributes
Behavior - determined by how the object acts or reacts to requests (messages) from other objects

An Object is represented as a rectangle with a underlined name in UML.

What is a Class?

A Class is a description of a group of objects with common properties (attributes), behavior (operations), relationships, and semantics

A class is an abstraction. An object is an instance of a class.

Example of a Class

Class: Course
Properties: Name, Location, Days Offered, Credit Hours, Professor
Behavior: Add Student, Delete Student, Get Course Roster, Determine If Full

A class is represented by a compartmentalized rectangle in UML. It has three sections - Name, Attributes, and Operations. You can show as many or as few of the Attributes and Operations in the diagram. Most of the times for the sake of clarity the Attribute and Operation lists are suppressed.

You start from real world objects - abstract out what you do not care and go through the process of classification of what you care. A Class is the result of this classification. Classes are then used as templates within a software system to create software objects.

What is an Attribute?

An Attribute is a named property of a class. It has a type. It describes the range of values that that property may hold.

What is an Operation (Function)?

An Operation is a service that can be requested from any object of the Class to affect behavior. An Operation can either be a command or a question. A question should never change the state of the object only a command can. The outcome of the Operation depends on the current state of the object.

What is Polymorphism?

The Greek term polymorphous means "having many forms". Interfaces allow us to define polymorphism in a declarative way. Two elements (classes) are polymorphic with respect to a set of behaviors if they realize the same Interface. Interfaces allow us to build a "plug-and-play" architecture. Classes that realize the same Interface may be substituted for one another in the system, thereby changing the implementation without affecting the User.