This is a discussion on adding existing parent object to extended child object? within the PHP Language forums, part of the PHP Programming Forums category; Tony Marston a écrit : > "Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in > message ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Tony Marston a écrit :
> "Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in > message news:40c6f920$0$7708$636a15ce@news.free.fr... > >>Tony Marston wrote: >> >>>Once you have extended a (parent) class and created a (child) subclass > > it is > >>>simply not possible to add another parent to that child class. This > > applies > >>>to all OO languages, not just PHP. Each child class can have only one >>>parent. >>> >> >>Tony, I hope this is not what you meant ? Many (non cryptic) OOPLs offer >>multiple inheritence (C++, Python, Common Lisp...). > > > I meant that PHP does not support multiple inheritance. Neither does Java. > That's not what you said... May I quote ? "This applies to all OO languages, not just PHP. Each child class can have only one parent." PHP and Java are far from being "all" OOPls (and I'm not quite sure PHP4 can really be classified as OO)... If I didn't know who you are, I would have called you a clueless newbie !-) Bruno |
|
|||
|
pablo a écrit :
(please dont top-post -- fixed) > > "Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in > message news:40c6f920$0$7708$636a15ce@news.free.fr... > >> But inheritence >>is far from being the alpha and omega of OOP. Aggregation|composition + >>delegation is another way to reuse code (ok, this means having more code >>to write, but what, this is straightforward...) >> (snip code) >> >>Now you can use Child as either a Parent object, a Child object, or a >>Mixin object... >> >>One advantage of aggregation|composition ws inheritence is that it can >>be dynamic : >> (snip more code) > In my view personnel inherits some properties of the class humans, f.i. > name, sex, date of birth. yes, but this does not make a 'personnel' a subclass of human. Let's have one simple exemple : in a business app, I have entities[1] like customers, employee and suppliers. I also have entities like individuals and companies. [1] "entities", not "classes". It's analysis, not design nor implementation, right ? Now here are (some of) the rules : an employee is an individual a customer may be either an individual or a company a supplier may be either an individual or a company an employee may also be a customer a supplier may also be a customer a customer may also be a customer an individual, formerly employee, may stop being an employee and become a supplier As you can see, we can not model this with a simple "class and inheritence" scheme. So let's analyse further and find what is *not* subject to change. This bring us to : - a company is always a company - an individual is always an individual The other rules can now be expressed as : - both can act as suppliers and/or as customers - only individuals can act as employees Clearly, we have to notions : "being" (individual, company) and "acting as" (a customer, supplier, employee). The first notion wont change with time, the second will. From a *design* POV, modeling 'employee' as a subclass of individual would be an error, since an 'individual' object should 'jump' from one class to another when it becomes an employee or supplier or stop being one. The best design I could think of in this exemple is to have classes "Company" and "Individual", and <role> classes "Customer", "Supplier" and "Employee". Customer and Supplier instances are 'composed of' either a Company or Individual instance, to which they delegate some responsabilities. Employee instances are 'composed of' an Individual instance, to which etc... > When I extend the class personnel with humans I can use the properties and > methods of humans and add to these some other properties and methods. You can also do this with [aggregation or composition] and delegation. > Now, humans have to exist before they can become personnel. This only depends on the business rules of *your* application. If you're only interested on employees, you don't even need the 'individual' class. > So when I > instantiate personnel the humans constructor is automatically called. No > Worries. > But how can I add a human(s) that already exist to my personnel class? You don't "add" an object "to" a class. An object is an *instance* of one particular class (and - if you respect the substitution principle - of its parent classes). What you ask for is "how do I build a 'personnel' object from a 'human' object. This answer is quite evident : pass the a 'human' instance as a parameter to the 'personnel' constructor. Once it's done, you have to ways to proceed : - the dirtyHackSolution : copy attributes of the 'human' object to attributes of the 'employee' object. This seems quite simple and obvious, but also leads to an obvious wart : once the copy is done, you have *two different objects*. - the cleanDesignSolution : just store that reference in the 'personnel' instance, and delegate every 'human' specific message to it (you can even add some 'personnel'-specific behavior before and/or after the 'delegate' call). Now none of those two solutions is an 'absolute best choice', this all depends on the problem your app needs to solve (the 'business domain' if you want to be buzzword-compliant !-) and what language you're using (ok, here it's PHP, land of all tricks... ). The dirtyHackSolution may be a 'good enough' solution, as long as 1/ you're confident in the fact that no one will talk to the 'human' instance once it has been copied to a 'personnel', and 2/requirements dont change. > That is all I need and want. That may be all you want, but not what you really need !-) (but this, only *you* - and your app's users - can tell). > Tia HTH Bruno |
|
|||
|
"bruno modulix" <onurb@xiludom.gro> wrote in message news:40c76534$0$13817$626a14ce@news.free.fr... > Tony Marston a écrit : > > "Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in > > message news:40c6f920$0$7708$636a15ce@news.free.fr... > > > >>Tony Marston wrote: > >> > >>>Once you have extended a (parent) class and created a (child) subclass > > > > it is > > > >>>simply not possible to add another parent to that child class. This > > > > applies > > > >>>to all OO languages, not just PHP. Each child class can have only one > >>>parent. > >>> > >> > >>Tony, I hope this is not what you meant ? Many (non cryptic) OOPLs offer > >>multiple inheritence (C++, Python, Common Lisp...). > > > > > > I meant that PHP does not support multiple inheritance. Neither does Java. > > > That's not what you said... May I quote ? > > "This applies to all OO languages, not just PHP. Each child class can > have only one parent." What I actually wrote was:- <quote> Once you have extended a (parent) class and created a (child) subclass it is simply not possible to add another parent to that child class. This applies to all OO languages, not just PHP.</quote> The statement: <quote>Each child class can have only one parent.</quote> applies to PHP in particular as it does not support multiple inheritance (just like Java). > PHP and Java are far from being "all" OOPls (and I'm not quite sure PHP4 > can really be classified as OO). PHP 4 does support Object Oriented programming in that you can achieve encapsulation, inheritance and polymorphism which are the fundamental principles of OO. The fact that it does not support ffeatures that other people dreamed up later is (IMHO) totally irrelevant. > If I didn't know who you are, I would > have called you a clueless newbie !-) I am used to people calling me names when I express opinions which are different from theirs. -- Tony Marston http://www.tonymarston.net |
|
|||
|
"pablo" <pablok@exeit.removethis.demon.nl> wrote in message news:10cdjsvte5l549f@corp.supernews.com... > Dear NewsGroupers, > > I am relatively new to OOP and cannet get my head around this problem. > I have two classes. Class Child extends Parent. > There is no constructor for the Child class. So when I create a child object > the constructor for the parent object is called. That works fine. > > But now I have the problem that I want to add an already existing Parent > object to create a new Child object. How can this be done? > > TIA > > pablo Well, pablo wrote ..... and got several interesting replies. I sincerely thank those that enlightened me. Thank you! pablo |
|
|||
|
Tony Marston wrote:
> "bruno modulix" <onurb@xiludom.gro> wrote in message > news:40c76534$0$13817$626a14ce@news.free.fr... > (snip some precisions...) > >>PHP and Java are far from being "all" OOPls (and I'm not quite sure PHP4 >>can really be classified as OO). > > > PHP 4 does support Object Oriented programming in that you can achieve > encapsulation, inheritance and polymorphism which are the fundamental > principles of OO. The fact that it does not support ffeatures that other > people dreamed up later is (IMHO) totally irrelevant. I forgot to enclose my later remark in a pair of '<troll>' tags, sorry !-) for ($i = 0; $i < 100; $i++) echo "I shall not forget the '<troll>' tags no more<br>"; > >>If I didn't know who you are, I would >>have called you a clueless newbie !-) > > I am used to people calling me names when I express opinions which are > different from theirs. Tony, you understand what a smiley is, don't you ?-) |