Object Oriented Programming Fundamentals

Introduction
Object orientation, these words can wreak havoc in the minds of developers everywhere. It doesn’t need to be this way though. Object orientation
is actually a much more direct method of mapping business problems to program code than any methods we have had in the past.
As an approach to system design and construction, object orientation is not a drastic change in how we build things. The same principles that we
have always used still apply. Spaghetti code is bad, structured code is good. Encapsulating functionality into discrete blocks of code results in
better maintainability.
However, object orientation requires that we adjust the way we think about what we do. Changing methodology is fairly easy. Most of us have
learned more than one programming language in our careers and it wasn’t the end of the world. But changing the way we think, well that is
another beast altogether.
What Is Object Orientation?
Object orientation is an approach to software development in which we focus on objects and their attributes and responsibilities. All business
problems involve things. These things can be mapped to a set of objects, such as customers, invoices, etc. In any given business problem the
various things have attributes like name, color, weight, etc and they have responsibilities such as initiate and order, fulfill an order, pay an
invoice, etc.
The object oriented approach of system building starts with the earliest phase of analysis of the business problem. In this early phase we center
on identifying the objects involved and what their attributes and responsibilities are. One interesting part of object orientation is that it closely
parallels the real world, much more so than the traditional structured approach of system design. This allows for a more thorough and accurate
modeling of the business problem in the system design.
Object orientation can be defined as, a system of components which encapsulate data and function, inherit these things from other components,
and communicate via messages with one another.
In the object oriented approach we not only identify the objects required, but we also organize them into classes of objects.
What Is the Difference Between a Class and Object?
Edward Yourdan defines a class as, “A collection of one or more objects with a uniform set of attributes and services, including a description of
how to create new objects in the class.”
Grady Booch defines an object as, “An object has state, behavior, and identity; The structure and behavior of similar objects are defined in their
common class; The terms instance and object are interchangeable.”
From these two definitions we can see that there is a difference between a class and an object. A class is the definition, or blueprint, for an object.
Classes don’t real ever exist, they are plans. We use the class to create an object which has identity. That is, an object exists, has values in its
properties and can execute behaviors.
This difference between a class and an object is a subtle but very important one. It is analogous to visiting an architect to have a new house built.
The architect will draw up plans for the house that show all the rooms and elevations etc. However, you cannot move into the plans and live
there. The plans must be used to build a house. The house is an object while the plans are a class.
Concepts of Object Orientation
Object orientation is more than classes and objects, it is a whole thought process about building applications. An object oriented development
language has many qualities that support the object oriented approach to system design and construction.
The concepts we will investigate are abstraction, specialization, encapsulation, inheritance, polymorphism, communication, and reuse. The
following sections discuss each of these concepts in detail. You may find situation where the various concepts are in conflict with each other, that
is fine because in the real world we often find our goals in conflict and we must make a decision and go with it.
Abstraction
This is the ability to represent a complex problem in simple terms. In the object oriented approach it is seen in the ability to create a high level
class definition that has little or no detail included in it. We are able to “abstract” the problem to a simple class definition and only add detail alter
in the process.
The ability to support abstraction is instrumental in being able to model very complex business problems in our designs.
Specialization
Seen in class structures, specialization is the ability to make lower level subclasses more detailed than their parent classes. Technically,
specialization is defined as the ability of an object to inherit operations and attributes from a superclass (parent class) with possible restrictions
and additions.
These first two concepts work in conjunction with one and other. Abstraction allows us to define high level classes that lack minute details of
implementation while specialization supports the introduction of those details later in the class design.
Encapsulation
Defined as hiding the implementation of the object, encapsulation is really the process of making an object as self sufficient as is possible. An
object contains not only code but also data. Encapsulation, in the structured design, is the process of enclosing all of the code necessary to a
particular operation into a single module and limiting the external dependencies of that module.
In object orientation, not only is the code encapsulated, but also the data required by that code (in the form of object properties).