If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Assume you have a base class of Shapes. Assume also that the class Shapes has a method called draw(). This class has descendants called circle, rectangle, etc. All of those descendants implements the method called draw.

Now, say you have a class called Canvas. This canvas will have children called Shapes. The canvas does not have to know how the draw method is implemented. All it has to do is to iterate on the children and invoke the function draw(). It will be up to the child to implement the draw function.

See, you're probably butting heads with explanations like the one @josephm provided, that uses all sorts of fancy words (that for someone like me who learned objects in "smalltalk" reeks of throwing new fangled terms at the simplest of concepts) but doesn't actually give you a practical example in plain English.

In general that was one of the things about Java that always pissed me off -- the concepts are simple, the tutorials, books, and language specification MAKES IT HARD.

Lemme use the example that was in the Turbo Pascal 5.5 manual. It is far simpler to understand.

Let's say you're making a game that is going to have four legged animals in it. You make a single parent class that contains all the information common to all four legged animals (properties) as well as basic behaviors (methods) -- like walking, resting, distant sound, angry sound. This gives you all the common code and a single uniform API for accessing an animal.

You then make a "feline" class that extends "animal" -- it sets the distant sound to a roar and the angry sound to a low growl. This pattern works well for most of the big cats without significant changes.

But then you want a housecat... changing those sounds to meow and hiss.

Even with the changes to each and every class along the way, ALL the different objects despite not sharing the same code, share the same API -- the same methods and properties you can look at to find out about the animal, to make it move, or to have it make noise.

This is why you'll often see base classes -- a "prototype" as it were -- that has all the methods defined, but don't actually do anything... yet. It's partly as a reminder that children of it should implement those methods, and partly as documentation.

A real world example comes from web browsers -- the DOM. Document Object Model. The core class on the DOM is a 'node'. ALL HTML elements are an extension of type Node, and all plaintext is assigned to an extension of node as well. They share common values like nodeType, firstChild, lastChild, nextSibling, previousSibling, parentNode -- but differ in how information inside them is tracked such element nodes having id, classname, name, etc, which do not exist on text nodes.

That common ancestry allows you to "walk the DOM tree" consistently even though each of the child nodes are different classes.

So bottom line the reason is twofold. First to allow for prototyping of future code to a common API, second is to reduce the overall code by sharing like properties and methods when possible.