Your full service technology partner! 
-Collapse +Expand
Search Coder Group:

-Collapse +Expand Coder Study Test
-Collapse +Expand Coder Store

Prestwood eMagazine

August Edition
Subscribe now! It's Free!
Enter your email:

   ► KBRole-Based T...Coding & OOObject Orien...   Print This     
  From the December 2015 Issue of Prestwood eMag
Coder Object Orientation (OO):
An Introduction to Object Orientation
Posted 17 years ago on 3/13/2003 and updated 1/26/2009
Take Away: Overview and introduction to object orientation. When you analyze, design, and code in an OO way, you "think" about objects and their interaction. This type of thinking is more like real life where you naturally think about how "this object" relates to "that object". Classes represent the "design" of an existing object. The values or properties of an existing object is it's current state. When designing classes, OO supports many features like inheritance (like real-life where you inherit your parents characteristics), encapsulation (hiding data), and polymorphism (the ability of one thing to act like another or in different ways).


Object orientation (OO) has changed the way the software industry approaches software development, in particular, how technologists approach analysis, design, code reuse, and implementation. This article will walk you through the mindset and fundamental concepts underlying object orientation.

An Object Viewpoint

Prior to OO, a typical application was viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the code logic. Although code logic and business rules are still important, object orientation focuses on the objects you want to manipulate rather than the logic required to manipulate them. Object orientation is an approach (not a specific tool) that is organized around objects rather than actions, data, or logic.

Why Object Orientation?

OO is organized around objects, their interface, how the objects communicate with each other, their state at a given instance, etc. Thinking of analysis and design of software as objects is very important because humans think in terms of objects. Everything around us is an object. For example, we think of a car, wallet, can of coke, table, and even people as objects.

Many objects are composed of other objects. A six-pack of coke consists of six coke cans and some type of container. A car consists of an engine, four or five tires, doors, etc.

Furthermore, we naturally think of objects as having characteristics such as color and state such as a tire either being on an axle or in the spare tire compartment. When we see someone running across a field, naturally and instantly, we catalog his or her current state. We catalog many characteristics including rough height, rough age, sex, clothes, hair color, whether they're running a fast sprint or a slow jog, type of field they're running across, etc. Object Orientation takes advantage of these natural instincts and applies them to software development.

Classes and Objects

A class is a set of similar operations and attributes, and an object is an instance of a class. You can think of a class as the design of an object that will be created in your code. Both classes and objects have identity. A class defines attributes and methods, while an object uses them.

  • Class - A set of similar operations and attributes that defines a class's behavior and attributes.

  • Abstract class - Cannot be instantiated.

  • Concrete class - Can be instantiated.

  • Object - An object is an instance of a class and has identity, behavior, and state. The available methods define its potential behavior.

A class specifies the data elements and data formats that combine to reflect what an object "knows". For example, you may create an object called Spot from a class named Dog. The Dog class defines what it is to be a Dog object, and all the "dog-related" messages a Dog object can act upon. All object oriented languages have some means, sometimes called a factory, to "manufacture" object instances from a class definition. You can make more than one object of this class, and call them Spot, Fido, Rover, etc. The Dog class defines messages that the Dog objects understand, such as "bark", "fetch", and "roll-over".

Attributes, and Properties

Classes and objects have characteristics. Examples of characteristics for a person are age, height, weight, and IQ. These characteristics are referred to as class attributes and object properties. Class attributes and object properties are also known as member fields.

Object State

Because an object has the ability to set the attributes, objects are also said to have state. The current values of an object's properties are its current state.

Operations and Methods

Classes and objects have actions. These actions are referred to as class operations and object methods. We'll refer generically to them as methods. A method is the implementation of an object service; it is simply the action that a message carries out. It is the code, which gets executed when the message is sent to a particular object. Arguments are often supplied as part of a message. For example, the "fetch" message might contain an argument that says what to fetch, like "the-stick" or "the last two records in a table". Or the "roll-over" message could contain one argument to say how fast, and a second argument to say how many times.

Message Calls

In OO you send a message from one object to another. Methods and properties are message calls. The parameters of a method are the message content.


The concept of a class makes it possible to define subclasses that share some or all of the main class characteristics. This is called inheritance. Inheritance also allows you to reuse code more efficiently.

Easier Maintenance

Because the code is broken into easy to understand classes, code maintenance is easier to perform. Many times while debugging, you'll narrow your search down to a single class and then a single method of that class.

Inheritance in the Real World

The following are a few concrete examples:

  • A tire inherits all of the characteristics of rubber but adds shape. A radial tire inherits all of the characteristics of a tire, but adds wire.

  • Spaghetti and lasagna noodles inherit all of the characteristics from Pasta dough and add shape.

  • A child inherits characteristics from both parents (a good example of multiple inheritance). How are the problems of multiple inheritance handled in humans?

The following are a few abstract examples of class inheritance:

  • Think of Plato's concept of the "ideal" chair that stands for all chairs.

  • In automobile manufacturing, you can think of a generic vehicle class with descendants of 2 wheel and 4 wheel vehicles. From 4 wheel vehicles descendants can include specific makes and models.

Inheritance in Software Development

The following are some examples of inheritance as implemented in the real world. These simple examples are provided to help bridge the gap from OO theory to OO usage:

  • Inherit from an existing class in an existing library. For example, with Delphi from the VCL or CLX libraries and with VB.NET from the .NET framework.

  • Create your own class library (or package).

  • Visual form inheritance. For example, in Delphi with each software title you can create a few default forms that all other forms inherit from. In this way, you can easily control many aspects of all the forms including default font attributes.

  • Actor inheritance in use case diagrams. A manager that has all of the abilities of a clerk can be represented on a use case diagram as inheriting from the clerk.


Encapsulation is the hiding of data and code and is often called the "black box" approach, since users of a class can't see inside the class (they can only see the class' public interface).

Encapsulation and Messages

Objects interact with each other by messages. The only thing that an object knows about another object is the object's interface. Each object's data and logic is hidden from other objects. This allows the developer to separate an object's implementation from its interface. As long as the interface remains the same, any changes to the internal implementation are transparent to the user.

Encapsulation and Coupling

Dependencies are sometimes known as coupling. A system with high coupling has high dependencies. A good system has low coupling and encapsulation promotes low coupling.

Encapsulation in the Real World

You can compare encapsulation to a battery that has a public interface consisting of a positive terminal and a negative terminal. We users of this battery don't know "exactly" what's inside (nor do we care), we just know that it does what we need it to do.

Encapsulation in Software Development

The following are some examples of encapsulation as implemented in the real world.

  • Hide code in custom classes, custom components, DLLs, etc.

  • Understand and use the private and protected scope directives correctly.

  • In Delphi, use the scope directives of each form as intended. If you add a function or procedure to a form, don't just add it to the implementation section. Use the OO way, and add it to the appropriate class scope (private, protected, etc.) of the form class.

  • Work on your public interfaces to "lock" them once deployed to more than "one" use.


Another benefit of separating implementation from behavior is polymorphism. Polymorphism allows two or more objects to respond to the same message. In other words, polymorphism allows any descendant class to redefine any method inherited from its parent class. The effect is that polymorphism allows a sending object to communicate with different objects in a consistent manner without worrying about how many different implementations of a message exist.

Polymorphism in the Real World

An analogy of polymorphism to daily life is how students response to a school bell. Every student knows the significance of the bell. When the bell (message) rings, however, it has its own meaning to different students (objects). Some students go home, some go to the library, and some go to other classes. Every student responds to the bell, but how they respond to it might be different.

Polymorphism in Software Development

The following are some examples of encapsulation as implemented in the real world:

  • method overloading

  • operator overloading

  • the use of common method names with classes in different inheritance lines

  • class substitution


Abstraction is a process in which you analyze a set of classes in an effort to discover a simpler ancestor class. The ancestor class will have attributes and operations in common. To abstract a set of classes, you find the attributes and operations that are in common and move them to a new ancestor class.

  • Abstract Class - A class that cannot be instantiated (this is a pure abstract class). Used to define a common interface.

  • Abstract Method - An abstract method is a virtual or dynamic method that has no implementation in the class where it is declared. Its implementation is deferred to a descendant class. In many development environments, the ability to abstract a method allows you to implement polymorphism in your application.

Abstraction and Cohesion

Cohesion refers to the strength of a method as it relates to the routines within it. A method has strong functional cohesion when it does just one thing. Abstraction promotes high cohesion.

Encapsulation versus Abstraction

Abstraction means the developer doesn't need to know more than what's surfaced in the interface, while encapsulation means that the developer can not know more than what is in the interface.

Code Reuse

Software development process experts that hope one day software development will mimic the electronics industry. In today's electronics industry, you can go down to your local electronics store and buy various components to build appliances. You don't care about the implementation details inside the component. You just care about the interface and component usage. Although the software development industry has a long way to go before achieving the same level of reuse as the electronics industry, today's software development industry is better than ever and on the way to true component-based programming.

Code reuse can be either commercial (pre-existing and controlled by another organization) or custom (created by and controlled by the development team creating the software). It is almost always more expensive to develop software than to purchase it. Each development team and its respective organization should actively seek out reusable commercial software.

  • Software Specific - Software specific code reuse is tied to the custom software title under development. Even with no planning, this is very attainable with every software title developed. This is the easiest type of code reuse to implement in the real world.
    Within your development environment, you simply move reusable routines into libraries; preferably, with the proper analysis, many of these routines become methods of classes.

  • Tool Specific - Tool specific reusable routines are specific to a development environment general enough to be used with more than one custom software title. Examples include Delphi components, Paradox libraries, C++ Header files, etc. With a little bit of planning, this level of code reuse is very attainable with each software development tool adopted.

  • Platform Specific - Platform specific reusable routines are specific to an operating system and are general enough to be used with more than one custom software title. Examples include Windows DLLs, Windows ActiveX controls, Linux .SO files, etc. With proper planning, you can have a moderate amount of success with each platform adopted.

  • Platform Independent - Platform independent reusable routines are not specific to an operating system and are general enough to be used with more than one custom software title. With use of the proper technologies and lots of planning, this type of code reuse has recently become possible. Potential solutions for platform independent code reuse you should consider include CORBA and XML Web Services.

Object Modeling

The first step in OOD is to identify all the objects you want to manipulate and how they relate to each other, an exercise often known as object modeling. Object modeling is a very similar process to data modeling used by DBAs to create relational databases. Once you've identified an object, you generalize it as a class of objects and define the kind of data it contains and any logic sequences that can manipulate it. The logic sequences are known as methods. A real instance of a class is called an object. The object or class instance is what you run in the computer. Its methods provide computer instructions, and the class object characteristics (or attributes) provide relevant data.

Code Reuse and Inheritance

Inheritance allows a class to have the same behavior as another class and extend or tailor that behavior to provide special action for specific needs. Inheritance promotes reuse. You don't have to start from scratch when you write a new program. You can simply reuse an existing repertoire of classes that have behaviors similar to what you need in the new program. For example, after creating the class Dog, you might make a subclass called Wolf, which defines some wolf-specific messages, such as hunt. Or it might make more sense to define a common class called Canis, of which both Dog and Wolf are subclasses. Much of the art of OO programming is determining the best way to divide a program into an economical set of classes. In addition to speeding development time, proper class design results in far fewer lines of code, which translates to less bugs and lower maintenance costs.

Object Modeling and Platform Independent Design

The object oriented analysis and design you perform on each software title is platform independent. Since class design (object modeling) is platform independent, you can get reuse from one development tool to another and from one platform to another.

The Abbreviations: OO, OOA, OOD, OOP

Let's continue our discussion of object orientation by defining OO domains based on common abbreviations:

  • OO - Object Orientation (OO) is the general term used when talking about the concepts and philosophy of object orientation.

  • OOA - Object oriented analysis (OOA) deals with investigating the problem domain using object oriented approaches. For example, when you identify possible object candidates from the problem domain such as customer, employee, clerk, invoice, etc.

  • OOD - Object oriented design (OOD) deals with the design of software. For example, from the analysis documents you will design classes with attributes (properties) and methods (functions and procedures) and their usage.

  • OOP - Object oriented programming (OOP) deals with the tool you use to implement the design specification.

Although terms and term usage vary slightly depending on domain, the underlying OO concepts do not. For example, in the OOA and OOD domains you say, "A class has operations while an object has methods." However, OOP is specific to a development environment like VB.NET or Delphi, and in that case, it is more accurate to use the terms of the development environment. For example, Borland Delphi uses the term method interchangeably with both objects and classes, even though technically a method belongs only to an object. The bottom line is, although you should use terminology as precisely as possible, don't get too hung up on it. In this article, I will use terminology precisely.

Making the Most of OO

To make the most of OO, you need to perform OOA, OOD, and OOP. Here are some guidelines:


  • Learn various OO techniques for gathering requirements (including Use Case Diagrams).

  • Learn techniques for extracting potential classes, methods, and properties from traditional text based requirements. One technique correlates nouns to classes, adjectives to properties, and verbs to methods.


  • Learn how to create class hierarchy diagrams.

  • Learn about business objects and how to design them.


  • Learn specifically how your OO development environment tool implements object orientation. Does it support visual inheritance? If so, how can you use it?

Learn About UML

The excepted best practice in today's software development industry for documenting object oriented software is the Unified Modeling Language (UML). You don't need to buy an expensive tool to use the UML. Once you learn the UML shapes, concepts, and usage, you can use pencil and paper to write down quick diagrams. It is often much faster during a requirements or design session to use pencil and paper. Later, if needed, you can transfer the diagram to a UML tool for archiving, updates, and publishing.

Every Project Isn't OO

Not every project should use an object oriented approach. For example:

  • Web Sites " Presentation web sites do not benefit from an OO approach. In fact, an OO approach is likely to add cost and time to the project. Although a presentation style web site is software development, the process you follow is more closely related to the process of putting together a brochure.

  • Non-OO Development Environments " If you use a development environment that is not object oriented, then your use of OO is limited. Non-OO tools in common use today include Corel Paradox and Microsoft Visual Basic 1-6.

What's an OO language?

Although incomplete and simple, the following gives you an idea of the minimum required to make a language object oriented:

  • Classes - The language must allow the developer to design a class complete with operations (object methods) and attributes (object properties).

  • Object Instantiation - The language must allow the instantiation of classes as an object and allow the developer to "call" the methods and use the properties of that object.

  • Inheritance - The language must support at least single inheritance. Because of the debate about the validity of multiple inheritance, multiple inheritance is not considered a must. Other forms of inheritance, including visual inheritance, are a plus.

  • Encapsulation - The language must support at least private, protected, and public scope directives. (Some languages add other scope directives. For example, Delphi adds a published directive that means the class method or property is public and will be displayed on the object inspector.)

  • Polymorphism - The language should support a method of surfacing polymorphism in design and usage. For example, the language should support method overloading, the use of common method names with classes in different inheritance lines, and class substitution.

Object Based and Class Based Languages

An object based language does not have the ability to create classes but does have objects available that you use in an object oriented way usually using dot notation. ObjectPAL is an example of an object based language.

A class based language is a partially object oriented language that is missing key concepts. Usually this means that you can create and use classes in your code but inheritance either doesn't exist or is very limited. ASP Classic and VB Classic are examples of class based languages.

Object Oriented Languages

One of the first object-oriented computer languages was called Smalltalk. There is around two-dozen major object oriented programming languages in use today. But the leading commercial OO languages are far fewer in number. On the Windows platform, the most popular OO development environments are Object Pascal, C++, Java, VB.Net, and C#.

  • Object Pascal - Object Pascal is the development language used by Borland Delphi and Kylix development environments and a few others. Borland Delphi is Windows specific and Kylix is Linux specific. One of the best advantages of using a Delphi / Kylix solution is that you can develop a true Windows and Linux binary executables from the same source code. Although Object Pascal does not support multiple inheritance, it is considered a fully object oriented language.

  • C++ - C++ is an object-oriented version of C. It is compatible with C (it is actually a superset), so that existing C code can be incorporated into C++ programs. C++ programs are fast and efficient, qualities which helped make C an extremely popular programming language. However, to take full advantage of object-oriented programming, one must program (and think!) in C++, not C. This can often be a major problem for experienced C programmers. Many programmers think they are coding in C++, but instead are using an Object Oriented development environment in a non-object oriented way. Specific C++ development environments include Borland C++Builder and Microsoft C#.

  • Java - Java is the latest object-oriented language. The Java standard is owned by Sun. It has taken the software world by storm due to its close ties with the Internet and Web browsers. It is designed as a portable language that can run on any web-enabled computer via that computer's Web browser or on any computer running a Java virtual machine (a runtime). As such, it offers great promise as the standard Internet and Intranet programming language as well as a way to develop cross platform applications using a runtime system. Java is very closely related to C++, but it has improved on C++ in some important areas. For one thing, it has no pointers (a difficult concept for many programmers to grasp). Specific Java development environments include Borland's JBuilder, Symantec's Visual Cafe, and Sun's own J2EE development environment.

  • Visual Basic.Net and C# - Microsoft has added true inheritance with the recently released VB.NET. Visual Basic, with the new release of VB.NET, is now fully object oriented. Visual Basic.Net is based both on VB Classic and the .Net CLS so it exhibits two personalities within one language. For example, you can use the VB-ish MsgBox "hello" or the .Net-ish MessageBox.Show "hello".


This article introduced you to object orientation. Now it's up to you to figure out how to put object orientation to use in your software development efforts. Read as much as possible on object orientation and decide how YOU can add OO to your specific analysis, design, and programming tasks.

More Info

Link: UML Home Page
Article:  Introduction to OO for the Paradox Community
Article:  Introduction to the Unified Modeling Language
Article:  OO/UML: Aggregation versus Composition
Definition:  Polymorphism
KB Post:  PSDP Phases compared to UML Workflows
KB Post:  PSDP: Step 2 Planning Overview (Gen & Design Phases)


Share a thought or comment...
First Comment
Comment 1 of 4
Your "objects" link in the Why Objects parragraph does not work???? Thanks for the article
Posted 15 years ago

Comment 2 of 4
Thanks gempark. I fixed the links (removed em cuz they weren't supposed to be there). Also, you're welcome. This was a particularly satisfying article to write.
Posted 15 years ago

Comment 3 of 4

Today I updated this article with minor updates to reflect changes in the industry (the popularity of C#) and some further clarifications (class based vs object based languages).

Posted 12 years ago

Latest Comment
Comment 4 of 4

Thanks Brian. Viva la CA Burger!

Posted 11 years ago
Write a Comment...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.

Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P191A1
Enter key:
Article Contributed By Mike Prestwood:

Mike Prestwood is a drummer, an author, and creator of the PrestwoodBoards online community. He is the President & CEO of Prestwood IT Solutions. Prestwood IT provides Coding, Website, and Computer Tech services. Mike has authored 6 computer books and over 1,200 articles. As a drummer, he maintains and has authored 3 drum books. If you have a project you wish to discuss with Mike, you can send him a private message through his PrestwoodBoards home page or call him 9AM to 4PM PST at 916-726-5675 x205.

Visit Profile

 KB Article #100137 Counter
Since 4/2/2008
Go ahead!   Use Us! Call: 916-726-5675  Or visit our new sales site:

©1995-2020 Prestwood IT Solutions.   [Security & Privacy]