Posted by "Colin Shreffler" on 10/24/05 08:44

I don't particularly care for this explanation as it makes abstract classes
out to be a mere convention of some kind during the development life-cycle.

While I can see this as a potentially convenient byproduct of the fact that
an abstract class cannot be directly instantiated, this is NOT the whole
story as they do have a much greater purpose: They provide polymorphism and
encapsulation to class hierarchies.

Certainly you can't instantiate an abstract class, but abstract classes
exist so that the implementation details of certain methods can be deferred
to their derived classes further down the inheritance hierarchy. Abstract
classes can also contain implementations for other non abstract methods.

Abstract classes and Interfaces can be used in combination in MANY different
patterns and frameworks.

I think that I know what you might be getting at here, but it is not true to
say it would be a class that shouldn't be instantiated as a 'sanity check'
for junior developers. It should be used to define classes that are truly
abstract; those where it doesn't necessarily make sense to have a 'physical'
manifestation but where it would provide reusable code to its derived
classes.

An example of an abstract class might be 'Vehicle'. Well that is too vague
(abstract) so you wouldn't really instantiate it. Instead you'd define more
useable derived 'concrete' classes like Car, Truck, Scooter, Airplane,
Bicycle, or Skateboard. Each of these are well defined so it makes sense
for these to non-abstract.

Each of these derived classes would then override the Vehicle's abstract
function start() for example, because each one would do this in a different
way. But by defining 'Vehicle' as abstract and defining the abstract
function start() in it (because 'Vehicle' itself would not have an
implementation for start()), you guarantee that each derived class MUST
provide its own unique implementation for that function.

Colin

-----Original Message-----
From: Richard Lynch [mailto:ceo@l-i-e.com]
Sent: Sunday, October 23, 2005 11:12 PM
To: Alan Lord
Cc: 'Jasper Bryant-Greene'; php-general@lists.php.net
Subject: RE: [PHP] Abstract Classes?

On Sun, October 23, 2005 5:40 am, Alan Lord wrote:
> But what benefit is there is having it as an explicitly "abstract"
> class? Why can't it just be a "normal" class definition which you
> inherit from?

It could be just a normal class...

But assume you're working on a team with a LOT of programmers, which
is where OO really shines.

Then assume some of those programmers are... less experienced... than
others.

They're not supposed to instantiate that one Class, because it doesn't
make any sense to do that, and it's bound to cause errors somewhere
else down the line.

Have an "abstract" class as a formal definition means that if you KNOW
it should never get instantiated, you have a Safety Check on it.

The compiler can error out if somebody, like our Junior Programmer,
tries to instantiate it.

If it's just a "normal" class, maybe Junior manages to make things
work (God knows how) even while instantiating a Class that was never
meant to be instantiated, and that the Expert Programmers would KNOW
was wrong.

It's just a Sanity Check, basically.

So, sure, it COULD be a normal class, if you want to assume nobody
will ever make the mistake of instantiating it... Or it could be an
abstract class, and if somebody screws up and instantiates it, they'll
know right away and fix it before the problem goes any further.

Hope that helps.

--
Like Music?
http://l-i-e.com/artists.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Back to original message]