Class named Object

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
dbevfat
Forum Contributor
Posts: 126
Joined: Tue Jun 28, 2005 2:47 pm
Location: Ljubljana, Slovenia

Post by dbevfat »

I agree with arborint here. Inheritance can be useful but mustn't be abused. As a rule of a thumb, inheritance relationship should be looked upon as a is a relation, otherwise it's probably just abusing inheritance for convenience. With exceptions, of course.

Can't really say, because I don't know your exact goals, but I've done it quite a lot a while ago and all I got was a little convenience for a price of a very static and fragile hierarchy and inflexibility.
Begby
Forum Regular
Posts: 575
Joined: Wed Dec 13, 2006 10:28 am

Post by Begby »

I use a base object in PHP5 but only to override __get() and __set() and to have those throw an exception whenever they are called as a hillbilly way of keeping myself from calling non-declared object properties. I can see how it might be useful for testing though in some cases.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I can understand why you might want to do something like that. Only I would probably call that class Propertied or ValueObject or something, rather than Base or Object. And I'd probably only use it for classes that actually needed that functionality.
(#10850)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

DNAObject is primarily a value object with specialized property lists that allow for more control on the access of properties than merely public, protected and private provide. Most of the objects, but not all, inherit from this class. It uses finalized __get and __set and __call methods to assert this control. The plan is to support plugins to these to provide for an avenue of augmenting the execution further, if need be.
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Post by superdezign »

Uh-oh. feyd's doing it too. :P

The base object "Object" is soo Java/JavaScript. The magic methods already "imply" a base object of sorts, so why bother making a base object out of a another base object?
User avatar
anjanesh
DevNet Resident
Posts: 1679
Joined: Sat Dec 06, 2003 9:52 pm
Location: Mumbai, India

Post by anjanesh »

The base object "Object" is soo Java/JavaScript
- so is .NET.\
PHP supports OOP but is not built-on on OOP.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

feyd wrote:DNAObject is primarily a value object with specialized property lists that allow for more control on the access of properties than merely public, protected and private provide. Most of the objects, but not all, inherit from this class. It uses finalized __get and __set and __call methods to assert this control. The plan is to support plugins to these to provide for an avenue of augmenting the execution further, if need be.
You spoke about this a long time ago and I thought it was a brilliant idea and then mused over it for a number of months deciding not to do it for several reasons:
  • Non-obvious low level behaviour that has to be explained to programmers to have any chance of understand what is going on in the code base
  • Reflection is difficult/complicated
  • Problems with generating documentation
  • Risk that functionality will be moderately inappropriate to some classes. This is of course true with any inheritance but considering how widespread the usage of this is the risk is greater. If you choose not to use it on some classes than behaviour becomes yet more unpredictable and non-obvious.
  • More code to maintain, temptation to tweak having far reaching implications.
  • Performance hit
  • One, indeed most, can write perfectly good code without it
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ole give an excellent summary of this issue. Obviously people create base objects in PHP and have done so since objects were introduced. However, because some people have very specific preferences on object behavior does not mean that in general it is a good practice in PHP. I have encountered many more programmers and frameworks that have had to undo this decisioin than add it.
(#10850)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

ole wrote:Non-obvious low level behaviour that has to be explained to programmers to have any chance of understand what is going on in the code base
It's fairly straight forward in my code base. If you're accepting of the default property permissions it's a simple matter of initializing the property in the constructor. Specifying alternates permissions isn't too difficult either in that you create a permissions data object filling the bits as needed and pass it to DNAObject's property factory.
ole wrote:Reflection is difficult/complicated
Using the reflection system, yes, but these properties aren't engineered for reflection, they are mostly geared toward renderable or highly interactive objects.
ole wrote:Problems with generating documentation
I haven't had any problems. Care to elaborate?
ole wrote:Risk that functionality will be moderately inappropriate to some classes. This is of course true with any inheritance but considering how widespread the usage of this is the risk is greater. If you choose not to use it on some classes than behaviour becomes yet more unpredictable and non-obvious.
The classes that do not inherit from this are, for the most part, inaccessible to the other programmers due to their low-level location in the layering. They can interact with them if they really choose, but they do so at their own risk.
ole wrote:More code to maintain, temptation to tweak having far reaching implications.
Not for this system. :)
ole wrote:Performance hit
I'll agree, there is a performance hit, but that's what programmers get when they choose to sidestep accessors and mutators. :)
ole wrote:One, indeed most, can write perfectly good code without it
The system is intended to keep silly mistakes from happening, not by highly experienced programmers, but the ones interacting with the system, who are more often than not, inexperienced.
User avatar
anjanesh
DevNet Resident
Posts: 1679
Joined: Sat Dec 06, 2003 9:52 pm
Location: Mumbai, India

Post by anjanesh »

ole - combining these classes into a a phar solves a lot doesnt it ?
Esp the idea of porting a package.
Post Reply