getters and setters in a class

ma1colm

HI!

Can anybody tell me what the advantages are of creating small getter and setter functions within a class (eg below). It just seems like more typing, but there must be a reason for it :S

function  setTmpName($tmp_name){
$this->tmp_name = $tmp_name;
}
function  getTmpName(){
return $this->tmp_name ;
}{

... rather than just assigning variables using

$this->tmp_name="malc"

Rgds

Malc

paulnaj

Hi Malc,

Yes it can seem a little pointless sometimes, especially for small project but some of the benefits are:

1) Consistent style across many classes means easier-to-read, easier-to-build and easier-to-debug code.

2) In your example, no extra processing occurs inside the setter function at the moment, but suppose later, you decide to change the functionality of the class. For example (this is a rather pointless example but you can see what I mean) suppose you decide to store tmp_names as lowercase, but names are passed to the setter function in any case ...

$myobj->setTmpName('Malc');
$myobj->setTmpName('MALC');

To effect the change, you only need to alter the code within the setTmpName() function ...

function setTmpName($tmp_name){
$this->tmp_name = strtolower($tmp_name);
}

... rather than everywhere that the 'simpler' code ...

$this->tmp_name = "malc"

... is called.

Hiding the details of functionality inside classes is one of the main reasons to use OOP in the first place!

Paul.

jazz_snob

When using object oriented solutions your objects encapsulate info they need to do the things you ask them to do. In general peeking inside at an objects vars w/ getXXX() and setXXX() defeats the whole purpose of object-oriented design -- yes there is controversy here. Google for articles written by Allen Holub on the subject. ( eg: "Why getter and setter methods are evil" and while your at it "Why extends is evil" ).

I try not to provide setXXX() methods, and only write getXXX() methods when necessary, for example a Customer object might have a getName() function. If there is no setXXX() then the value is read-only.

In general, an object that only has getters and setters is probably not a good design. Of course, your method might be something like getHTML(), which I use, but its not returning an object var, the object is actually doing something, on its own, and giving me back a string; eg:

//display contents of shopping cart
$cartView =& new CartView( $_SESSION[ 'cart' ] );
echo $cartView -> getHTML();

Overall I find object oriented solutions HARDER to create than purely procedural solutions but much more powerful and easy to maintain.

-Tom

PS good OO-design ideas are scattered everywhere, here's one i like on 'being a Good Citizen

ma1colm

Hmmm...well i have no intention of dipping into objects using set or get, and my code is probably for my eyes only. There is an angle i have not grasped maybe, cos I can relate to paulnaj's comments on how it helps to maintain encapsulated code when a class develops over time. BY providing just get functions for objects (read only), are you talking about programmers abusing a set function if it were to exist? NOt sure what the security threat is here. Mabe i should execute that Google search you suggested 😉

Thanks to both of you for the feedback.

RGds
Malc

Weedpacket

It's not so much a security measure to provide get() and set() instead of simply exposing the property (and providing only get() if the property is to be read-only); just plain defensive programming.

If there are any restrictions on the type of data that should be stored in a property (and there almost always is: it's probably silly to try and store a socket resource in a property that's supposed to represent a person's age!), or if there are relationships between properties, or if the same properties could be looked at in different ways (a complex number class, for example, can be written in both cartesian and polar forms - only one needs to be stored and the other can be calculated on demand), then get()/set() methods provide that level of control.

And if you allow someone to write a value into a property that is supposed to be read-only, someone is eventually going to try it. And almost certainly break something in the process.

Remember Murphy's Law: If there are two ways of doing a thing, and one of them is wrong, someone will do it that way.

ma1colm

So, in my casae where im writing a class to verify uploaded files, i might want to set an array of allowable MIME types. The set function would chk that i had written ".jpg" and not just "jpg". The get function would then be an encapsulated source of known valid data to be fed into another function within the class.

Is this what paulnaj means by being easier to debug code and easier to read it?

Rgds

Ma1c

ma1colm

Haha! There is no black and white ~here~ is there!! For future browsers of this thread:

Why getter and setter methods are evil by Allen Holub:
[URL=http://]www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html[/URL]

PHP getter/setter debates:
[URL=http://]www.sitepoint.com/forums/showthread.php?t=169846[/URL]
[URL=http://]www.sitepoint.com/forums/showthread.php?t=127823[/URL]

MAlc

ma1colm

OK, one last thing 🙂 Since im in the company of some fine PHP minds [grovel], at a glance, is the following file upload class a good ~design~ template for other classes. It seems planning and design are important if accessors are to be used to best effect if at all. IWS from my newbie OOP stanpoint, the example implementation of this class given at the end of the article displays encapsulation.

[URL=http://]www.phpfreaks.com/print.php?cmd=tutorial&tut_id=85[/URL]

Malc

paulnaj

Hi Malcolm,

I'll have to have a proper look at the phpfreaks class before commenting, but it looks OK at first glance.

Just to go back to the main thread though, having looked at the 'evil' articles, I do feel that the principles argued over are a bit academic with respect to PHP, at least PHP on the server-side.

A lot of the benefits of OOP are found in building GUI's, where an object may remain in memory for the duration, delivering and receiving messages from other objects. This just doesn't apply to PHP on the server-side, where direct interaction (using a GUI) is irrelevant.

So I think you can take a lot of the 'evil' discussion with a pinch of salt. For me, OOP makes PHP more readable and easier to upgrade and debug.

Just for a example, I use a general Page class which stores all of the basic page properties that every page on the website will need (title, stylesheet, javascript, meta-tags etc).

It's not always necessary, but if there are many different types of page on the site, then I would extend (eek!) the general Page class to 'particular' pages. For me, this is just 'handy' and practical.

I also use single instance of a very general MySQL class that does ALL of the interaction with mysql. I use the same class for every site I'm working on. That's handy, too.

Paul. 🆒

ma1colm

Paul

It's a relief to hear about the different programming environments. I have often read that for simple web apps, OOP is not that justifiable. But, i suppose its a survival tool for the future as web pages/apps inevitably become more complex.

INteresting that you initiate vars in a general page class. Until now i have had a config.ini file with things like $CO_NAME = "Hoover Ltd", which Ive included on all php pages. ONly recently i read a CMS class [URL=http://]www.intranetjournal.com/articles/200408/ij_08_05_04a.html[/URL] that uses a main parent class to set such site specific variables. Other classes extend this main class and so inherit these vars. Is this acceptable practice IYO?

RGds

Malcolm

paulnaj

Malcolm,

Yeah, I'd actually read the first couple of chapters of that article sometime ago and it's very good. I'm sure it's acceptable practise.

I couldn't quite see the point of the SystemComponent object though, since only the DBConnector class seems to use the $settings data. So why not just put the settings in the DBConnector Class?

I quite liked the Validator Class and might actually nick that!

About your config.ini file ... it's not, in principle, much different to my Page object. Both of us are creating 'globals' (which purists often frown on, but I just can't quite seem to do without). The only real difference is that I only create one global - the Page object - and use getters to extract the actual data.

As far as 'ease of use' goes, all I do is plonk a copy of the Page.php in a folder above the root, open it up, fix the settings once and that's it ... it's all laid out for me. Similarly, I put a copy of my DB.php in the same folder and fix the settings. That's a lot of basic stuff I don't really have to think about every time I start on a new site, but it's nothing you couldn't do procedurally.

Just to show the other side, I use a set of functions to build HTML, usually a different set per site. I did start to go down the OOP route, but in the end, I found that it made it hard to work with designers, virtually all of which wanted to tweak the actual HTML/CSS after the design process was supposed to have finished.

So, for me, it's always about practicality.

Paul 🙂

PS. Sorry if I'm teaching grannies to suck eggs but one thing I would say about using a .ini file extension is that if a user is able to navigate to that file, then it's possible that they would be able to view the contents so make sure to put it in a folder above the root folder.

ma1colm

Paul I dont quite see the benefits of using a Page class to create an object with global variables accessible through getters? There must be some benefit over using a simple config.ini file to set globals!? And I wonder how the 'purists' tackle this?

Rgds

Malc

ma1colm

PS. Sorry if I'm teaching grannies to suck eggs but one thing I would say about using a .ini file extension is that if a user is able to navigate to that file, then it's possible that they would be able to view the contents so make sure to put it in a folder above the root folder. [/B]

Found this:

And for the extra-paranoid like myself, add a rule into your httpd.conf file so that .ini (or .inc) in my case can't be sent to a browser:

<Files *.inc>

Order deny,allow
Deny from all
</Files>

...whilst looking at how parse_ini_file() might help me with config files here: http://uk.php.net/parse-ini-file

Malc

paulnaj

Hi Malc,

No, the only real benefit of my Page Class is that it's organised in a way that suits me!

I'm really not sure what the 'purists' would think of my Page class ... I was quite encouraged by that CMS article though, which isn't fundamentally different to the way I do things.

The thing about PHP is that it's a real hotch-potch anyway. That's not a criticism, I'm a big fan of PHP over Perl, say, for it's ease of use.

About the httpd.conf file ... I've found that ISP's don't always allow you to alter it for yourself (especially if the site you're working on is on a shared server, which has been the norm), so other ways often have to be found.

Paul 🙂