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@xxxxxxxxx] Sent: Sunday, October 23, 2005 11:12 PM To: Alan Lord Cc: 'Jasper Bryant-Greene'; php-general@xxxxxxxxxxxxx Subject: RE: 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
