Thanks, That's starting to make some sence now! Al > -----Original Message----- > From: Colin Shreffler [mailto:colin.shreffler@xxxxxxxxxxxxxxxxx] > Sent: 23 October 2005 17:03 > To: Alan Lord; 'Jasper Bryant-Greene' > Cc: php-general@xxxxxxxxxxxxx > Subject: Re: Abstract Classes? > > One reason would be that you might not know the details of a > derived class's implementation details at design time. > > For instance I could have an abstract class such as this: > > Class MyTestClass > { > function doSomething() > { > doSomethingElse(); > } > > abstract function doSomethingElse() ; } > > As you can see I have an abstract function with no details. > I know that when the doSomething() function is called it must > call the doSomethingElse Function, but at the time that I > define MyTestClass I don't know what that is exactly. > > Now say another developer needs to derive a class from > MyTestClass. Because the base class is abstract they must > define an emplementation for the doSomethingElse class such as: > > Class MyDerivedClass extends MyTestClass { > function doSomethingElse() > { > // here the developer must specify the specifics of > what this method does > } > } > > Now in our business logic if we do the following: > > $myClass = new MyDerivedClass(); > $myClass->doSomething(); > > The code will actually execute the doSomethingElse() > implementation that has been defined in MyDerivedClass. > > This can be extremely useful in developing frameworks that > you want other developers to extend on their own and also in > business systems where you might need to maintain a system by > adding new classes/implementations over time. Certain > patterns also make heavy uses of interfaces and abstract classes. > > Perhaps a real-world example would make more sense. Does > this help? If not, let me know and I'll come up with a > similar/real-world example. > > Colin > > On 10/23/05 4:40 AM, "Alan Lord" <lord_alan@xxxxxxxxxxx> wrote: > > > Thanks Jasper, > > > > That makes sense. > > > > 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? > > > > Sorry to be so dense.... > > > > Al > > > >> -----Original Message----- > >> From: Jasper Bryant-Greene [mailto:jasper@xxxxxxxxxxx] > >> Sent: 23 October 2005 09:19 > >> To: Alan Lord > >> Cc: php-general@xxxxxxxxxxxxx > >> Subject: Re: Abstract Classes? > >> > >> On Sun, 2005-10-23 at 08:54 +0100, Alan Lord wrote: > >>> Hi All, > >>> > >>> I have started reading a couple of books about PHP 5 and > >> whilst most > >>> of it is comprehensible even to me :-), I fail to > >> understand WHY there > >>> is such a thing as an abstract class or method? > >>> > >>> I think I understand what it is: A class that can't itself be > >>> instantiated, only inherited from, or a method that > >> describes itself > >>> only in terms of what properties it accepts but no implementation > >>> detail. > >>> > >>> But could someone explain why I would want to use this? I'm > >> sure it is > >>> very useful but I can't quite see the benefit... > >> > >> Hi Alan > >> > >> Here's an example from an application framework I've been > working on. > >> > >> It has classes to represent the different HTTP response statuses > >> (like > >> 301 Moved Permanently, 304 Not Modified etc.) with required and > >> forbidden headers for each and different characteristics (like no > >> request-body allowed etc). > >> > >> I have an Abstract class called HTTP_Response, from which > >> HTTP_Response_Moved_Permanently, > HTTP_Response_Not_Modified, and many > >> others all inherit. > >> > >> The reason HTTP_Response is abstract is because there's no > such thing > >> as an HTTP_Response on its own. It has to be a specific > type of HTTP > >> Response, that is a 301 Moved Permanently or a 304 Not Modified. > >> > >> Does that help? > >> > >> -- > >> Jasper Bryant-Greene > >> General Manager > >> Album Limited > >> > >> e: jasper@xxxxxxxxxxx > >> w: http://www.album.co.nz/ > >> p: 0800 4 ALBUM (0800 425 286) or +64 21 232 3303 > >> a: PO Box 579, Christchurch 8015, New Zealand > >> > >> > > > Thank you, > Colin Shreffler > Principal > 303.349.9010 - cell > colin.shreffler@xxxxxxxxxxxxxxxxx > > Warp 9 Software, LLC. > 6791 Halifax Avenue > Castle Rock, CO 80104 > > Confidentiality Notice: The information in this e-mail may be > confidential and/or privileged. This e-mail is intended to be > reviewed by only the individual or organization named in the > e-mail address. If you are not the intended recipient, you > are hereby notified that any review, dissemination or copying > of this e-mail and attachments, if any, or the information > contained herein, is strictly prohibited. > > > > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
