Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm an old school top-down procedure programmer. I started with Turbo Pascal on the DOS environment. Every time I try to learn OOP on my own I stumble.

I try and make OOP somehow fit into my top-down mindset. It's very frustrating, I seem to have a mental block.

What is the best way for someone like me to learn OOP?

share|improve this question
What languages and what tutorials have you been trying to use? –  S.Lott May 4 '11 at 14:26
You might want to check this out. –  Mahmoud Hossam May 4 '11 at 14:52
Did you try reading Head First Java? It gives a good precursor to OOPS & what its all about! –  Venki May 4 '11 at 15:54
what part of the concept are you having trouble with? At the very core, its simply grouping a bunch of "properties" (various data types) + a bunch of methods (or functions). I know its a-lot more than that. –  Darknight May 4 '11 at 17:01
@Steven - Thanks. 90 seconds huh! I'll check it out. –  Michael Riley - AKA Gunny May 5 '11 at 2:46

12 Answers 12

up vote 10 down vote accepted

If you're used to Turbo Pascal, you ought to start with Delphi (or Free Pascal, an open-source clone of Delphi) so you'll already be familiar with the basic feel of the language. That way you aren't trying to learn two unfamiliar concepts at once.

As for understanding OOP from a procedural starting point, think about it this way:

A procedural program can be thought of as a collection of variables and code that takes input and uses it together with the internal variables to do a certain job. Object-oriented programming is that same pattern repeated on a smaller scale, applied to individual components of your program.

Each object is a collection of variables bound to procedures and functions (known collectively as "methods" when they're part of an object) that, being procedures and functions, can take input from the outside world, and work together with the internal state to do a certain job.

It can be understood quite easily from a top-down perspective. For example, in a Delphi program, your application is managed by an object called Application. It contains information about the state of the program as a whole, and provides a built-in message/event loop that dispatches input events to your forms. Each form is an object that describes the user interface, plus code to define what happens when the user does something. When the user initiates something (by clicking on a button or a menu option, for example,) it's frequently handled by creating an object of the appropriate type for whatever task needs to be performed, then calling a method on it.

The benefit of this paradigm, thinking of objects as the same model as a program but on a smaller scale, is that you can build your program out of several smaller, more-or-less independent components. (And the more independent of each other, the better. That's known as loose coupling.) That reduces the number of details you have to hold in your mind at once when working with the code, and makes your program more robust and easier to modify and maintain.

The other major difference between procedural programming and object-oriented programming is Liskov substitution, which is a technical term meaning that object classes can inherit from other classes, and any instance of an inherited class can be treated by the program as if it was an instance of the class it derives from.

This allows all sorts of new opportunities for flexibility that are too involved to get into here, but keep in mind as you start to work with an OO language that when you see a method parameter that accepts an object type, what it really accepts is that class or anything that derives from it. The main benefit of this is polymorphism, which refers to declaring a virtual method on the base class and then overriding it (providing a new implementation) in inherited classes. When a virtual method is called, the compiler inserts code to call the version of the method belonging to the actual object, not the method belonging to what the object is currently declared as.

To give one simple example, in Delphi there's a class called TStream that is used for data streams. It has virtual methods called Read and Write which are used for reading from or writing to the stream, respectively. It has several descendant classes, including TFileStream for accessing a file on disc, TMemoryStream, which uses an in-memory buffer, and an HTTP stream whose name I can't recall at the moment. Each is implemented in a very different way, but if you're in a method with a TStream parameter, you don't need to know or care how it works; you just call Read and Write and the other virtual methods.

Hope this helps you understand OOP a little bit better. :)

share|improve this answer

You learn by doing. It took me several years of writing C++ before I "got" OOP. It means that a lot of my early C++ code looks like C with a personality disorder.

It's a different mindset, and it takes a while to adjust.

share|improve this answer
+1 just for "C with a personality disorder" –  GreenMatt May 4 '11 at 18:03

I think the fastest way to go there is to try Ruby.
It's easy to install, there's a great introduction online and you can also try it online to get a first impression (It actually goes as far as creating your own class and doing something with it)

Why Ruby?

  • it is purely object oriented
  • it is very popular (unlike other purely object oriented languages) and a framework like Rails allows you to really build an actual application (although you should learn the language first)
  • it is very concise, expressive and elegant ... in other words, it's fun
  • it is easy to read and easy to write, so you can really focus your bending your mind around OOP instead of spending much time learning some language's idiosyncrasy. It doesn't add all the weird restriction Java and C# do, and all the very-powerful-but-orthogonal-to-OOP features C++ has.

And how to? Well, this is what I would do:

  • Try it online if you want to. It will already give you an idea where you're headed.
  • Get Ruby. Fire up the IRB.
  • Read through Programming Ruby. Anything you want to try, just type into the IRB.
  • Get Rails and a suitable IDE
  • Go through some of their tutorials and try to understand, why they are doing certain things. Come back to stackoverflow, if you can't figure out why. Also, if something appears magic, investigate, how it is implemented. Slowly dive into the framework's code, to see how a database abstraction layer is implemented, and things like that.

From there, you should have a good idea about OOP. You may want to move on then, or you will find happiness with Ruby itself, who knows. Personally, I didn't stick with Ruby due to its lack of static typing, but that's something you should see for yourself.

Lastly, I would like to mention the SOLID principles. They are quite simple, but truly understanding them and learning to implement them takes a while.
Also, you may want to have a look at popular design patterns, although knowing them is far less important then understanding them (and recognizing the underlying principles).

share|improve this answer
Great answer. Python is also very popular, concise, expressive, and elegant, and would be a good starting point. –  Neil G Jun 17 '11 at 21:50

For me it took me a couple of years in order to be able to work with an OO mindset, while understanding the concepts was a matter of taking a uni-class...

So with this granted, a good way to bypass the mental block is outside help. Thought of books? I would suggest head first labs on object oriented programming, may I suggest java?

Also in order to bypass a mental block (in coding), I usually experimented with different approaches. If you are experienced, how about shadowing a developer for a bit?

share|improve this answer

First i would really like to clarify that Top-Down is a methodologie to solve problems and not a paradigm ( you could use top-down to create object oriented soft solutions).

Now, about a way to get around objects is think about a record/strut type or ADTs (Abstract data types) are the most close you could ever get in procedural to what an Class is. Well, Classes are more or less like ADTs , they could be instanciated, have variables in them of different types and also functions you could call. They also add things like Polimorphism and Inheritance but, i would really recommend you to start with the basics, and get yourself a good OO Programming Reference book (link to another SO question about that).

share|improve this answer

When I first learned about OOP, I interpreted all that talk of objects, and how they were built by composition of other objects, in terms of properly designed relational databases, which I already knew. The OO-talk of messages I mapped mentally onto functions and procedures. All that helped, but only a little. I still wasn't able to build something object oriented that didn't totally suck. Sure, I had the classes and objects and methods and data members but I wasn't able to do anything interesting with all that, let alone something I wouldn't have been able to do with much less effort without OO.

Then I stumbled upon Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al., which helped a lot. There I learned the Why to the How, and also many useful techniques for implementing object oriented software. Maybe it could be of some help to you too?

share|improve this answer

Hey, Another Turbo Pascal Programming Here.

I learnt Procedural Programming with Basic, applied Procedural Programming with Turbo Pascal, and, later, learnt O.O.P. with Turbo Pascal.

You should see each procedural program as a big single object. An each object as a single program. When I learn O.O.P. I said: "Cool, objects are little programs that can share stuff with others, or can be composed of little programs !!!"

Procedural Program that looks like a single Object

program Helicopter;
uses Crt;

function TurnOn;

function TurnFly;

function TurnOff;




Single Object Example

program Helicopter;
uses Crt;

  HelicopterClass = object
    function TurnOn;
    function Fly;
    function TurnOff;

function HelicopterClass.TurnOn;

function HelicopterClass.TurnFly;

function HelicopterClass.TurnOff;

var MyHelicopter: HelicopterClass;






share|improve this answer

Is there any scope for you to take a class? As it happens, that's what I wound up doing five or six years ago.

share|improve this answer

I would suggest you read David West Object Thinking.

I do think it is a bit over the top and kinda "spacey/hippy-dippy" in parts. Ignore those parts or skim over them.

What the book does is present OOP as a mindset/way of thinking and gives some good ways to start thinking that way. Doesn't tell you how to program in OOP but that isn't the hard part of OOP.

share|improve this answer

If you're at all familiar with Perl, you might want to give Moose a try (and even if you're not, you might want to give it a shot, anyway). For example:

package Person;
use Moose; #you get "use strict" and "use warnings" for free!
use DateTime; 

#attributes: first and last names are strings, and are rewritable
has 'first_name'=>(isa=>'Str',is=>'rw');
has 'last_name'=>(isa=>'Str',is=>'rw');

#The birth_date is an actual DateTime object that defaults to now.
#It's also read-only.
has 'birth_date'=>(isa=>'DateTime',is=>'ro',default=>sub{DateTime->now;});

#age is an integer that defaults to zero.
has 'age'=>(isa=>'Int',is=>'rw',default=>0);

#Methods are just subroutines.

sub happy_birthday
  my $self=shift; #grabbing the object.
  my $age=$self->age;
  print "Happy Birthday!  You're now $age years old!\n";

Note that there was no constructor. Moose provides a constructor of new by default. So, you can do:

use strict;
use warnings;
use Person;

my $me=Person->new({first_name=>"Jack",last_name=>"Maney"});

Inheritance is simple:

package Child;
use Moose;
extends 'Person';

#etc, etc

And one of the things that makes Moose really shine is that roles (aka mixins) are built right in. Roles encapsulate behavior that can be shared amongst classes. There are also lots of other things that I haven't fully explored yet, such as meta classes that allow for class introspection.

share|improve this answer


enter image description here

This book is a relatively short read, and well-written. It won't be sufficient for everything, but it will ease you into the OOP concepts.

share|improve this answer

You're in deep trouble, as OO is full of people full of crap.

In general, never listen to people telling you stuff could be more or less "object oriented" than it is, they are the crazy.

Learning Python may be the fastest way to get up to date, but don't get too attached to it, it's a toy language and some bad maintainance practices (and a bad business arrangement by Nokia) are keeping it grounded at 5% to 10% of its real potential.

Python comes with some severe confusion about indentation, but all in all, the fastest and more rewarding language learning experience I ever had.

I suggest you this book, it should teach you Python and object oriented features at the same time.
(there's also a Java and a C++ version, no C# one - I read the Java one, it was good)

Kids, well, they're taught C# today, little while ago they all used to do Java. If you ain't bothered about the competition, and coming from DOS, C# might be a sensible choice. (to settle on)

Visual Studio now has a free version, it's called Visual Studio Express.
You want to use it, while starting with C#.

share|improve this answer
ZJR please keep the tone of your posts professional at all times. –  Yannis Rizos Mar 5 '12 at 9:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.