Class named Object
Moderator: General Moderators
Class named Object
Many OOP languages have a base class called Object.
I want to create a base class called Object from which I want to derive all other classes.
Will creating a class named Object be an issue for future versions of php ? [ Remember nuSoap's soapclient conflict with PHP5's SoapClient ]
Is PHP6 implementing this kind of OOP structure ?
Thanks
I want to create a base class called Object from which I want to derive all other classes.
Will creating a class named Object be an issue for future versions of php ? [ Remember nuSoap's soapclient conflict with PHP5's SoapClient ]
Is PHP6 implementing this kind of OOP structure ?
Thanks
Re: Class named Object
I don't think it would be a bad idea. Changing it in the future would not be that hard. It simply a matter of personal taste.anjanesh wrote:Many OOP languages have a base class called Object.
I want to create a base class called Object from which I want to derive all other classes.
Will creating a class named Object be an issue for future versions of php ? [ Remember nuSoap's soapclient conflict with PHP5's SoapClient ]
Is PHP6 implementing this kind of OOP structure ?
I would highly recommend , no matter what you name it, that you use a base class.
If I use this base class in say 10 websites and all other classes that descend directly from Object will have extend Object and static methods like Object::foo() will exist.Changing it in the future would not be that hard
True, as feyd said avoids naming conflicts with third party code that someone may use.
but still...want to know if php6 is going to be totally Object Oriented like Java and .NET where a base class called Object will exist as a base ?
The convention I use is my initials prefacing all object names. Oddly though I don't do this with my base class.anjanesh wrote:If I use this base class in say 10 websites and all other classes that descend directly from Object will have extend Object and static methods like Object::foo() will exist.Changing it in the future would not be that hard
True, as feyd said avoids naming conflicts with third party code that someone may use.
but still...want to know if php6 is going to be totally Object Oriented like Java and .NET where a base class called Object will exist as a base ?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Class named Object
I would recommend against using a base class in PHP. I don't consider it to be a very good practice. Other languages tuck "universal" capabilites into all of their objects because everything has to be an object. PHP has no such constraint and helper functions are the practical solution in PHP (like it or not) and they can be lazy loaded. I do agree on the class naming prefix suggestions.
(#10850)
Re: Class named Object
Wow! I have never heard anyone give that recommendation before. One of the advantages of OOP is inheritance and using it from the beginning gives you capabilities of dealing with objects in generic ways that you would not of had with out it.arborint wrote:I would recommend against using a base class in PHP. I don't consider it to be a very good practice.
If you are going to have most of your objects inherit from nothing you might as well use functions.
Even if your base object contains nothing in the beginning you should have one because, trust me, before the project is completed your base class with have defined behavior.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I mean a base class. If you are creating a new class that does not obviously inherit from anything it should inherit from a class that defines a generic set of behaviors. Unless, of course, you are creating the class that defines those behaviors or special circumstances like proxy objects. It is almost always wise to have all your objects in a single project stem from a single object, that is having a base object that is referenced as the root object in your inheritance tree.arborint wrote:By base class I did not mean to never inherit -- I meant to have a single class that every class inherits. That is what the OP asked about. I consider that a poor practice in PHP.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
Class Objectsuperdezign wrote:But what "generic behaviors" would even be shared by *all* of your classes?
Error handling, testing (isThingy() methods), certain types of reflection, overwriting __toString, creating unique object identifiers, Objective-C style key paths....superdezign wrote:But what "generic behaviors" would even be shared by *all* of your classes?
Code: Select all
public function getByKeyPath($aStringKeyPath){
return $this->$aStringKeyPath();
}
public function setByKeyPath($aStringKeyPath,$value){
$methodName = "set".ucfirst($aStringKeyPath);
$this->$methodName($value);
}Check out http://www.oldenbuettel.de/squeak-doku/ ... bject.html for a bunch of ideas.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
This and the examples give by ev01 are exactly the reasons why I think it is a poor practice in PHP. Java does it that way because of the constraints of the language. PHP has a different design. If you want to code PHP exactly like Java then just use Java -- it is an awesome language. e01 would add __toString() capablity to all classes when only a very few actually need that functionality. Testing should definitely be external in my opinion.
(#10850)
Actauly as of PHP 5.2 all classes have __toString functionality built in. I just don't care for the format. For error reporting purposes all classes need __toString.arborint wrote:This and the examples give by ev01 are exactly the reasons why I think it is a poor practice in PHP. Java does it that way because of the constraints of the language. PHP has a different design. If you want to code PHP exactly like Java then just use Java -- it is an awesome language. e01 would add __toString() capablity to all classes when only a very few actually need that functionality. Testing should definitely be external in my opinion.
Making type testing external causes tightly coupled code and hurts maintainability and reusability. The object should encapsulate all it's behavior including testing (as much as the language allows).
Using a base object at a bare minimum can't hurt and in fact is hugely beneficial.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
If you use methods like that a lot then it may be of benefit to you. I prefer not to implement anything unless I really need it -- and then only where I need it. For me, convenience is the enemy of good design in the long run.ev0l wrote:Using a base object at a bare minimum can't hurt and in fact is hugely beneficial.
(#10850)