Copying an Object
in [General]
|
From: Daniel Kolbo on 25 Sep 2010 07:29 On 9/24/2010 9:49 AM, chris h wrote: > "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(a)cbord.com> wrote: > >> From: chris h >> >>> On Fri, Sep 24, 2010 at 8:35 AM, Peter Lind <peter.e.lind(a)gmail.com> >> wrote: >>> >>> On 24 September 2010 14:22, Bob McConnell <rvm(a)cbord.com> wrote: >>> > From: David Hutto >>> > >>> >> On Fri, Sep 24, 2010 at 4:09 AM, Gary >> <php-general(a)garydjones.name> 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 >> >> > All, Thank you for the various ideas, discussion, and book recommendation. I definitely need to check out that text. Thanks. dK ` |