Timeline for Simple PHP inheritance using an abstract class
Current License: CC BY-SA 3.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 24, 2014 at 22:25 | comment | added | Corbin | @php_nub_qq That certainly makes sense if it really is an attribute of each pet species. It's just a dangerous road to go down if you take that path then realize that the foods are actually per animal, not per species. Either way though, as long as you're aware of the tradeoffs, a case can be made in either direction :) | |
Aug 24, 2014 at 21:56 | comment | added | php_nub_qq | Makes sense, but I suppose I would be better off to have this little ambiguity, rather than to have the same information stored a number of times, for example if I utilize memchache every single pet object will have foods information stored in it, which is generally the same for each type of pet. Such a waste just makes no sense for me and I opt to avoid that. Cheers! | |
Aug 24, 2014 at 21:47 | comment | added | Corbin | @php_nub_qq I could have sworn PHP gets grumpy if you call a static method on an instance, but you seem to be right. That still feels a bit gross though as calling a static method on an object rather than a class implies that it belongs on the object, not the class. | |
Aug 24, 2014 at 21:40 | comment | added | php_nub_qq |
Boy was that a deep one! In the beginning I actually made it as an instance method, but then I figured, for my application, that all pets of the same kind will like the same food. So for that purpose I suppose this is exactly the way to go, do you disagree? Also in the example method doSomethingWithPetFoods(Pet $pet) getEdibleFoods can be accessed as $pet::getEdibleFoods() , which seems pretty natural and returns accurate information. Thank you for your detailed answer, even though I am, sadly, not fluent enough to rationalize a significant portion of it!
|
|
Aug 24, 2014 at 21:29 | history | answered | Corbin | CC BY-SA 3.0 |