PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 13:02:29 -060030http://www.phpdeveloper.org/news/20309http://www.phpdeveloper.org/news/20309
Accessing private class properties via getters and setters is a pretty standard way to write your applications. Unfortunately it can be time consuming to write them for every property your class may have. On 7PHP.com Khayrattee Wasseemhas a few ideas (including using PHP's own Reflection functionality) to dynamically create them.

When coding a project, at times (or most of it?) some classes might have more than 3 fields (for whatever reason it suits you). So instead of each time writing and repeating setters and getters (accessor methods), I would like to have a piece of reusable code for all my classes without me ever writing a single line of code for accessors. ('ever' as in 'very very rarely'). Now, we also have to take into consideration that some fields might be only get-able or only set-able - (our re-usable piece of code should cater for this)

He shows two different methods to accomplish this kind of dynamic access, one using traits and the other using normal class inheritance. HE includes the code illustration each solution and talks a bit at the end of each section of why that method might be better than the other.

Link: http://7php.com/magic-dynamic-properties/]]>Mon, 28 Oct 2013 12:57:14 -0500http://www.phpdeveloper.org/news/20166http://www.phpdeveloper.org/news/20166
Russell Walker has a recent post to his site looking at different ways to work with class properties including using them as public properties or using getters and setters.

Opinion seems to be divided on whether it is good practice to use public properties in PHP classes, or whether to use getter and setter methods instead (and keep the properties private or protected). A sort of hybrid third option is to use the magic methods __get() and __set(). As always, there are advantages and disadvantages to each approach, so let's take a look at them.

He breaks the rest of the post up into three sections, each with a bit of a code example and the common advantages/disadvantages. It's a good overview of the three types and, in the end, it's mostly about what works for your applications. What's his favorite?

My choice then is to use public properties most of the time, but getters and setters for critical settings that I feel need stricter control, would benefit from lazy loading, or that I want to expose in an interface.

Link: http://russellscottwalker.blogspot.co.uk/2013/09/public-properties-getters-and-setters.html]]>Thu, 26 Sep 2013 09:58:36 -0500http://www.phpdeveloper.org/news/17623http://www.phpdeveloper.org/news/17623
Josh Adell has a new post to his blog talking about a debate between developers over which is the better method - using public properties or getters and setters to work with values on your objects.

I was recently having a debate with a coworker over the utility of writing getter and setter methods for protected properties of classes. On the one hand, having getters and setters seems like additional boilerplate and programming overhead for very little gain. On the other hand, exposing the value properties of a class seems like bad encapsulation and will overall lead to code that is more difficult to maintain. I come down firmly on the get/set method side of the fence.

In his opinion, the getter/setter method provides an explicit interface to the class that describes what it can do and how you can work with it. He gives code examples, comparing the two methods - simple setting of properties on one object and using get*/set* methods on the other. He brings up the point that, if ever in the future you wanted to handle the data for a property differently, say always make it an array or object. He also points out that this still doesn't prevent the setting of new properties directly, so he uses the magic __get and __set to deal with that.

]]>Mon, 05 Mar 2012 09:50:21 -0600http://www.phpdeveloper.org/news/17336http://www.phpdeveloper.org/news/17336
In a quick new post to his blog, Rob Allen has shared a snippet for the Sublime Text 2 editor to make creating getters and setters for your class simpler (dynamically too).

As with a lot of editors, Sublime Text supports snippets which are essentially text expansions of a short phrase into more text. I needed to create a few getXxx() and setXxx() methods for some properties of a class and decided that the easiest way to do this would be with a snippet.

Included in the post is the code you'll need to put into the snippet - a simple find (regular expression based) looks at the currently selected variable and expands out the getter and setter for it. For more information on the Sublime Text 2 editor, see the product's website.

]]>Tue, 03 Jan 2012 09:54:23 -0600http://www.phpdeveloper.org/news/16580http://www.phpdeveloper.org/news/16580
Bence Eros has put together a new post to his blog looking at some of the results he's found from performance testing the use of getters and setters in PHP.

The usage of getter and setter methods instead of public attributes became very popular in the PHP community, and it's going to become the standard coding convention of so many PHP libraries and frameworks. On the other hand many developers - including me too - strongly unrecommend such convention, because of its performance overhead. I wanted to make some performance comparison for years, and today I had time to do that. In this post I would like to show what I found.

He starts with a question every developer asks as their working in their application - why and when should they use getters and setters for their classes. He talks about using them as primary functionality or as fallbacks only when needed. He includes the simple benchmarking script he used to compare accessing/setting public attributes directly and using a getter/setter to do the same. The results aren't very surprising if you think about the "magic" that has to happen for getters and setters to work. See the rest of the post for those numbers.

]]>Tue, 12 Jul 2011 11:39:18 -0500http://www.phpdeveloper.org/news/16349http://www.phpdeveloper.org/news/16349
Shawn Stratton has a new post to his blog talking about a topic he calls "flame bait" - the use of accessors in PHP applications (getters and setters) to access class properties.

Objects have prop­er­ties which some­times need spe­cial logic on how they are retrieved and set. There are sev­eral solu­tions to this and every­body has a dif­fer­ent view point about which is cor­rect, none are pretty and all have draw­backs which range from writ­ing extra code, cre­at­ing some­thing that has poor exten­si­bil­ity, or has issues with con­sis­tency. These don't even breach the issues with IDE code com­ple­tion and analy­sis. Lets look at some of these solutions.

The solutions are the direct access to the class properties (which can cause some painful inconsistencies when things get complicated) and the alternative of setting up getters/setters for everything. Shawn's alternative makes use of the __get and __set magic methods to catch the property values being set and handle them correctly, developers being none the wiser.

]]>Tue, 17 May 2011 14:46:32 -0500http://www.phpdeveloper.org/news/15951http://www.phpdeveloper.org/news/15951
On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

passing values in through the constructor

using the "Information Architect" pattern to have the most responsible method handle the value setting

the "Double Dispatch" method that uses dependency injection

using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.

]]>Wed, 23 Feb 2011 12:02:17 -0600http://www.phpdeveloper.org/news/15898http://www.phpdeveloper.org/news/15898
In a new post Berry Langerak wonders if the getters and setters commonly used in PHP applications are a necessary evil and if they should be used at all.

Although I do still feel like getters and setters are to be avoided most of the time, it's hard to tell where to use them and where you shouldn't. [...] While writing the code for [PFZ.nl], I started to notice that each and every class in the system had accessors for most, if not all, protected fields. I've started a discussion with my fellow developers, and this is what I've argued.

He mentions a few things including an article he'd written previously on the topic, some of the points behind OOP programming, encapsulation and accessors and collaborators. He also includes several code examples showing what he considers right and wrong ways to do thing (warning, opinions ahead).

All in all, I don't think accessors are evil per se, but you should only ever use the accessors in cross-layer situations. Don't use accessors to build functionality, but only because you need the value to display and/or save.

]]>Mon, 14 Feb 2011 09:57:30 -0600http://www.phpdeveloper.org/news/15608http://www.phpdeveloper.org/news/15608
In this recent post to his blog Michael Kimsal asked about the usefulness of the __get and __set magic methods and the sort of code he usually sees along with it.

For a long time I've held that __get and __set in PHP were not all that hot - mostly because it's solely error handling. There's no way to deal invoke __get or __set behaviour for properties that are defined on a class. [...] For those who insist on using __get/__set, I *typically* see this [messyy] sort of style code. The effect is to cram a bunch of unrelated code in to the __get/__set overloading methods.

He suggests an alternative to the "cram it all in __get" approach - callbacks to other methods in the class to handle the different variable possibilities. In the comments there's other suggestions on how to get the same job done differently - mapping property values with __call, valid uses for getters/setters and a pointer to an internals discussion RFC about this same thing.

]]>Tue, 21 Dec 2010 09:36:05 -0600http://www.phpdeveloper.org/news/12285http://www.phpdeveloper.org/news/12285
Adam Jensen has a new post to his blog today looking at a solution he's created to be able to access the raw input a user has entered.

I've run into a minor problem, and I'm not sure my solution is particularly ideal. See, the Zend_Form approach described above does a great job of implementing Chris Shiflett's Filter Input, Escape Output principle...user input is filtered for invalid HTML before it's ever saved to the model, and can then be escaped as appropriate in the view layer. But what happens if you need to be able to retrieve the user's original unfiltered input later?

While working with the raw data could be dangerous, he has created a custom model that, through the getters and setters and doing validation/sanitization and the presentation layer rather than behind the scenes. It's not ideal but he's willing to take suggestions...