RE: [PHP] Abstract Classes?
| From: | Alan Lord | Date: | Mon, 24 Oct 2005 10:06:41 +0000 |
| Subject: | RE: [PHP] Abstract Classes? | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-224541@lists.php.net to get a copy of this message | ||
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@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.
<snip>