RE: [PHP] class variables and methods

From: Date: Sun, 19 Aug 2001 15:47:35 +0000
Subject: RE: [PHP] class variables and methods
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-63400@lists.php.net to get a copy of this message
But when designing classes, isn't it normal to have private and public variables or properties. Granted my OOP experience is very limited, having access to OOP development in CA-Visual Objects, Clipper, VB, and ASP. But it was normal to have a series of public properties one could access directly and then properties that could only be access by the class itself. Of course in VB and ASP these were defined with Get, Let and Set methods, but you could still access them directly. You could also design properties that were read only as well. Perhaps this is because of operator overloading?? > -----Original Message----- > From: Tom Carter [mailto:subs@roundcorners.com] > Sent: Sunday, August 19, 2001 2:19 AM > To: Andrew Libby; Joe Sheble (Wizaerd) > Cc: General PHP List > Subject: Re: [PHP] class variables and methods > > > There was a long discussion on this in a java forum I am part of, the > product of which was basically this... > > 1. All variables in a class are best left to be private (not sure PHP has > this, but the programmer can work the principle in mind.. that is only the > class can access them). > 2. Generic variable access/store methods should be avoided - the principle > is that the internal variable can change name etc. without the external > interface having to worry about it. > 3. Method to set/fetch each variable - it may seem a counter intuitive way > of doing it, especially when it is possible to do something > "nice" like the > set method below. This seems a very "un-web" way.. and this is where a > difference comes in. Web is not inherently OO, and a lot of the > practices of > web programmers are at conflict with more "traditional" apps programmers. > Web tends to go for speed and simplicity, rather than good design etc. > 4. Some situations could theoretically arise where it is > necessary to set an > unknown amount of variables within a class, however it would be far more > sensible to put these into an array. > > In summary, in good OOP you should have a method for every > get/set operation > on variables that is required, using arrays as appropiate. > > Going back to the original point on whether or not to access the variable > directly or build a set function in, they are both as bad as each other, > just about. They both access variables directly and require the outside > program to have knowledge of variable names etc. and it doesn't allow for > checking for "correct" values being set ( a useful thin with the above > method) > > Hope this helps, let me know if I can provide any more advice. > > Tom > > ----- Original Message ----- > From: "Andrew Libby" <alibby@commnav.com> > To: "Joe Sheble (Wizaerd)" <JustForMailingLists@wizaerd.com> > Cc: "General PHP List" <php-general@lists.php.net> > Sent: Sunday, August 19, 2001 3:34 AM > Subject: Re: [PHP] class variables and methods > > > > Joe, > > There are varying opinions on this issue. The argument for > > methods is that it hides the internal structure of your class. This > > is always a good thing. This means that the internals of the class > > can be changed, but the user interface (the user is the programmer here) > > does not change. So this alternative implementation of someclass > > > > > > class someclass > > > var $data = false; > > > > function set($key,$val) { > > $this->data[$key] = $val; > > } > > } > > > > is no different the the calling code. In general, I tend to have an > > accessor/mutator method for each 'property' that I would like to > > provide access to. I'd have a method for each $key that I want to > > support (this may not apply in your case). > > > > class someclass > > > var $name = false; > > var $age = false; > > > > function name() > > > if(func_num_args()) $this->name = func_get_arg(0); > > return $this->name; > > } > > > > function age() > > > if(func_num_args()) $this->age= func_get_arg(0); > > return $this->age; > > } > > } > > > > Now, this gets a big annoying to code since the lions share of my > > classes have the name method implementations. I've been hunting > > for a way to create methods dynamically, but I've only found one. > > To create class definitions on the fly and eval() them. This > > works great when you've got a huge number of properties > > (class/instance vars). I'll construct a static method on the > > class that processes examines the class vars (get_class_vars()) > > and defines a class extending my implementation. The > > sub class has the methods implemented for accessing/mutating > > the properties I'd like to have methods for. If anyone knows > > of a means to do this to an existing class (say using create_function() > > or something), I'd love to hear about it. > > > > Andy > > > > > > On Sat, Aug 18, 2001 at 07:09:08PM -0700, Joe Sheble (Wizaerd) wrote: > > > I've been doing some reading up on OOP in PHP, and looking at some of > the > > > classes available on the web, and I've got what is probably a stupid > > > question. I've seen this many many times.. > > > > > > class someclass { > > > var $somevar = "someval"; > > > > > > function set( $key, $val ) { > > > $this->$key = $val; > > > } > > > } > > > > > > $myClass = new someclass; > > > $myClass->set( "somevar", "someotherval" ); > > > > > > why write a set method when you can just as easily call > > > $myClass->somevar = "someotherval"; > > > > > > Is there a reason for this? > > > > > > Also, alot of the different table classes (an OOP approach to HTML > tables) > > > stores the data in arrays, but at what point is it too much to store > into an > > > array? Say you have a forum and the text entered for a single respone > could > > > be quite lengthy, much less for 100 replies... wouldn't that be a bit > much > > > to store into an array? I know it depends on the system > resources, but > is > > > there a practical limit that people follow? > > > > > > > > > > > > -- > > > PHP General Mailing List (http://www.php.net/) > > > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > > > For additional commands, e-mail: php-general-help@lists.php.net > > > To contact the list administrators, e-mail: > php-list-admin@lists.php.net > > > > > > > -- > > -------------------------------------------------- > > Andrew Libby > > Director of Technology > > CommNav, Inc > > alibby@commnav.com > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > > For additional commands, e-mail: php-general-help@lists.php.net > > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > >

« previous php.general (#63400) next »