Articles : JavaBoutique's Introduction to Java : Q and A :

Procedural vs Object-Oriented Programming

Q

I enjoyed your article in javaboutique. I like your use of examples that we can all relate to in the real world and then examples used in the programming world.

I am procedural programmer trying to re-train myself in the object-oriented way. Can you recommend a book/article that does the following:

• explains the difference between classes and objects, methods, properties in simple terms - using examples like you did ( this is a hard concept for me to grasp )
• gives examples of how to code simple programs procedurally and then re-write the code in the object-oriented method ( this would help me understand the differences between the 2 programming methodologies )

A

The best book I have ever read on Object Oriented Design is called "Thinking in Java" and as it so happens, is free for download at www.bruceeckel.com

Of course, even though it is free, I would buy the book at your earliest convenience as the print-out would be just as costly as buying the book.

You will never grow tired of re-reading Bruce's comfortable prose and you will learn something new on each re-read.

Also, over the next few months I'll be continuing my Java Tutorial and will be covering classes, objects, methods, etc.....

Nevertheless, I will try to give you a preview now so that you can get moving with your reading right away....

A class is a programmatic representation of an object.

Okay, that was a mouthful...let me take a step back.....

So you recall that an object is like a "thing". An object has "properties" such as hair color, weight, gender, and it has "methods" such as breathing, thinking, running.

Let's consider a specific example though. Let's consider a Button object.

A Button object has properties. It has a color. It has a label like "Click Me!". It has a width.

A button object also has methods. A button can be clicked. A button can have a mouseOver effect. And a button can be disabled so that it may not be clicked.

Well, that is cool and theoretically, it is not hard to imagine a Button as an "object". But seeing a button as an object is only half the battle of becoming an OO programmer.

You also need to know how to represent the object as computer code.

Well, a "class" is the programmatic representation of an object.

A class describes programmatically all the properties and methods of an object.

Consider the following pseudo code:

Class Button {

	color = red;
	label = "Click Me";
	width = 40 pixels;

	click() {
		Create a clicked-in 3D effect;
	}

	disableClick() {
		Don't allow anyone to use my click() method 
		until I am again enabled and turn my text gray;
	}

	enable() {
		Cool.  Allow people to click me.
	}

	mouseOver() {
		Make myself fuzzy looking whenever the user moves the mouse over me.
	}
}

So as you can see, the Button Class defines the properties and methods of an object programmatically. Some people like to call it the "blueprint" of an object. It specifies what objects look like generically.

Usually, you will "instantiate" an object by using its class.

For example, I might say:

Now myButton is a full-fledged "object" that was molded into reality from the Button class cast. myButton can be said to exist whereas Button does not. Button is a generic definition. myButton is an actual implementation of the definition.

I can even do things like:

when I do so, I tell this living object (based on the Button class) to execute the code in its disableClick() method. Hopefully, I will have written code to make the button actually disable itself :)

Okay, now your second question....

Let's consider this little program written in a structural way:

	#!/usr/local/bin/perl
	my $a = 2;
	my $b = 3;
	my $c = $a + $b;
	print "The sum of $a and $b is $c";

	my $d = 3;
	my $e = 4;
	my $f = $a + $b;
	print "The sum of $d and $e is $f";
	exit;

Okay....pretty simple right? Now I could run this program and get the expected results. However, it is not a particularly elegant solution because I did a lot of "similar" work!

A better approach would be a modular structural design....

A well done, modular type structural program might be rewritten as:

	#!/usr/local/bin/perl
	print addNumbers(2,3);
	print addNumbers(3,4);
	exit;

	sub addNumbers() {
 		my $a = shift;
		my $b = shift;
		return ($a + $b);
	}

Notice that this second structural design is much better because it isolates functionality into subroutines.

There are two benefits.

import AdditonObject;
myAdditionObject = new AdditionObject(2,3);
myAdditionObject.printSum();           // prints 5
myAdditionObject.setNumbers(3,4);
myAdditionObject.printSum();           /// prints 7

class AdditionObject {
	
	int number1;
	int number2;

	new(int a, int b) {
		number1 = a;
		number2 = b;
	}

	setNumbers(int a, int b) {
		number1 = a;
		number2 = b;
	}

	printSum() {
		System.out.println(number1+number2);
	}
}