"Gang of Four" http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 An excellent book on OOP. Chris H. On Fri, Sep 24, 2010 at 9:34 AM, Bob McConnell <rvm@xxxxxxxxx> wrote: > From: chris h > > > On Fri, Sep 24, 2010 at 8:35 AM, Peter Lind <peter.e.lind@xxxxxxxxx> > wrote: > > > > On 24 September 2010 14:22, Bob McConnell <rvm@xxxxxxxxx> wrote: > > > From: David Hutto > > > > > >> On Fri, Sep 24, 2010 at 4:09 AM, Gary > <php-general@xxxxxxxxxxxxxxx> wrote: > > >>> Daniel Kolbo wrote: > > >>> > > >>>> Say you have two classes: human and male. Further, say > male extends > > >>>> human. Let's say you have a human object. Then later you > want to make > > >>>> that human object a male object. This seems to be a pretty > reasonable > > >>>> thing to request of our objects. > > >>> > > >>> I don't think any human can change gender without major > surgery, but I > > >>> don't know if you just chose your example badly or whether > you really > > >>> think objects should be able to mutate into other types of > object > > >>> without some kind of special treatment. > > >> > > >> But it would work in something like makehuman, where you > start with a neuter > > >> form and scale one way or the other for physical features. If > I > > >> remember correctly, > > >> we're' all xx until you become xy(genetically speaking). > > > > > > This is one of the details that really bothers me about OOP. > It makes > > it impossible to implement some very reasonable scenarios. 80% of the > time, > > when a patron is added to a system, we don't know which gender they > are. > > More than 50% of the time, we will never know, since the client > doesn't keep > > track of it. But the rest of them will be assigned sometime after they > were > > added. i.e. the gender assignment comes from a secondary source that > is not > > available at the time the patron is entered. > > > > > If you can't handle that, it's not the fault of OOP but your > lack of > > programming skills in OOP I'd say (and I mean no disrespect > there, I'm > > just pretty sure your scenario can be handled very easily in > OOP). > > > > And no, I have no urge to defend OOP in PHP, I just see this > entire > > thread as a complete non-starter: if the language doesn't let > you do > > something in a particular way, how about you stop, take a > breather, > > then ask if perhaps there's a better way in the language to do > what > > you want done? That would normally be a much more productive and > > intelligent response than either a) pressing on in the face of > failure > > or b) complaining about your specific needs and how the language > fails > > to meet them. > > > > I think pages 17-19 of the GoF covers exactly this: > > > > "Object composition is an alternative to inheritance." ... "Any > > [composed] object can be replaced at run-time by another as long > > as it has the same type." > > > > I would look into "object composition" or just read the GoF. > > GoF? > > Bob McConnell > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
