getters and setters in a class

[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 🙂