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
