Ah ha !!! Thanks Colin, I think I'm getting it now. That makes obvious sense to think of the abstract class as truly abstract in what it represents... Only thing is, this where I find most of my thinking about OOP falls down! I seem to be able to think of hundreds of classes which would be "abstract" [in the true meaning of the word] and I find it quite a struggle to come up up with useful classes that actually do represent real world objects :-) But that's just down my own ignorance/inexperience I think... Thanks for all the replies to this slightly OT post. Al Colin Shreffler wrote: > 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. <snip> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
