Why get/set methods?

[Widow Maker]

If he had provided a wealth of examples, he might convince me, but he doesn't.

there wasn't really a proven solution viable enough not to use Getters and Setters either

Once the design as settled, removing / rewriting dumb setters / getters that are redirecting data is probably a worthwhile exercise.

If you have the time of course Which is better off spent having some fun and relaxing over a few beers

[dagfinn]

Dagfinn try to post your comments with a bit of more ``elegance'', thanks.

OK. I don't see it, but I'll assume my comments were open to some interpretation that made them worth removing.

[pippo]

I think nominating Iraq was out the contest.
If you want we can discuss this by PM.

[Octal]

Also, most of his argument against getters and setters centers seems to center around typing issues that are not very relevant to PHP

In fairness the articles were written with regards to Java. Though I do agree that the article would carry more weight had he provided real world examples.

While development is in progress, using getters / setters gives you the option of being able to rename / remove a property, reflect the change in the setter / getter and leave all other code untouched. Once the design as settled, removing / rewriting dumb setters / getters that are redirecting data is probably a worthwhile exercise.

A viable solution, agreed. However if you forget or simply don't have the time to do this then you are risking maintainability headaches down the line. I suggest a more worthwhile exercise would be not to use dumb setters/getters in your design process in the first place

[lastcraft]

Hi

Why getter and setter methods are evil by Allen Holub.

Excellent articles. I always felt that frameworks that force you to inherit from their classes often caused as many problems as they solved. Like...er...SimpleTest does .

I try to avoid using getters and setters for most class members, except for those cases where it really makes sense to use them.

Another place they can creep in is, ironically, unit testing. In order to find out if something has had an effect on an object, the temptation is to peer inside. This is what makes mock objects so effective. They constrain behaviour and interactions rather than the current state. For example see this bit of code.

http://www.phplondon.org/wiki/BeerExample

The first part was written without mock objects and has the isDrunk() method. The second part, with the actual drinking, is a much more complete and clean expression of what the object does.

yours, Marcus

[Azmo]

If he had provided a wealth of examples, he might convince me, but he doesn't.

That's the same problem I had with Allen's 'Why extends is evil' article; he's using simplistic examples to provide a very one-sided view of the problem. I don't even agree with the term 'evil' in this case, because what it's all about in the end is our ability to make the right design choices. Sometimes we need getters and/or setters, but a lot of times we should avoid them.

I do think that getters and setters are dangerous though, since they break object encapsulation.

By designing carefully and focusing on what you must do rather than how you'll do it, you eliminate the vast majority of getter/setter methods in your program. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

I do agree with Allen on this. About the last line: the pragmatic programmers have an article Tell, Don't Ask on their site, where they discusses the same thing. And while I'm not too interested in Allen's opinions (sorry Allen ), I do have a lot of respect for Andy and Dave.

[dagfinn]

I do think that getters and setters are dangerous though, since they break object encapsulation.

Yes, in Java or PHP 5.

But not in PHP 4. Everything is public, so if you use getters and setters, you'll get more encapsulation rather than less. It doesn't enforce encapsulation, though.

The real issue applies to PHP 4, though: not using the object's data outside the object if you can avoid it. The Tell, Don't Ask article is focused on the principle rather than the language implementation, which makes it more relevant to PHP 4.

[dagfinn]

If you want we can discuss this by PM.

No thanks, but I think it might be useful if you made your criteria explicit--to everyone. I mean in general, without reference to a particular case.

Just a suggestion.

[Austin_Hastings]

No thanks, but I think it might be useful if you made your criteria explicit--to everyone. I mean in general, without reference to a particular case.

Just a suggestion.

Umm: "explicit, without reference to a particular case" ?

You don't ask for much, do you?

=Austin

[Widow Maker]

Now and again, we all get to the point where we really, really need to be explicit to get our own point of view across

Now and again, you get an administrator coming along, who feels they just have to censor a post, maybe because they can ?

Maybe they're bored ?
Maybe they think it'd be funny ?

Who knows, but it doesn't make it right.

Somehow

[dagfinn]

Umm: "explicit, without reference to a particular case" ?

You don't ask for much, do you?

=Austin

It's called rules; otherwise in society it's called laws. I couldn't care less about the two sentences you removed. I just think as a matter of principle that it's better if the rules are clear to everyone so they can avoid whatever it is you consider inappropriate.

Like I said, it's just a suggestion. Think about it if you want. Otherwise, forget it. I don't think there's a need to argue about it.

[pippo]

Stop it to talk here about that Dagfinn, you are going to be off topic of this thread.
Please stay on topic.

I think you are smart enough to understand things, if you are not that's not my problem.

Further answers offtopic from you here will be removed.
This is not the right place to discuss about that.

[dagfinn]

The pragmatic programmers have an article Tell, Don't Ask on their site, where they discusses the same thing. And while I'm not too interested in Allen's opinions (sorry Allen ), I do have a lot of respect for Andy and Dave.

Yet another angle on the same thing: getters and setters can be an expression of feature envy.

[Austin_Hastings]

Stop it to talk here about that Dagfinn, you are going to be off topic of this thread.
Please stay on topic.

I think you are smart enough to understand things, if you are not that's not my problem.

Further answers offtopic from you here will be removed.
This is not the right place to discuss about that.

Pippo,

I didn't see what was posted, so I'm not quite sure what Dagfinn did to put this particular bee in your bonnet. And since it happened some time ago, I don't care to know.

But he was responding to a comment addressed specifically to him from me, so I think it is you, not he, who are out of line here.

What's more, I (and probably some others) read your comment: "Further answers offtopic from you here ..." as a direct, punitive attack on Dagfinn.

I'm just as guilty, for speaking to him, as he is for answering.

I'd suggest that you provide a pointer to the "rules" and a citation of which "rule" was violated at any time you remove a post - it makes clear to everyone what happened. If there's no "rules" link to point to, then perhaps that is what Dag is talking about.

I looked around the forums, and I couldn't find a single place that seemed like "the right place to discuss this", which means either that: (1) SitePoint's policy is to prohibit discussions of this nature; or (2) this is equally as good (and equally as poor) a place for this discussion as any other .

=Austin

[dagfinn]

But he was responding to a comment addressed specifically to him from me

I know I've been instructed not to comment any more on this, but in the hope of clearing something up, let me just say this: I don't know why, but I got the two of you mixed up. That may have contributed to the confusion. Sorry about that.

Apart from that, I've said all I need to say about this subject.

[pippo]

I was not going to punish anyone, it's not in my shoes.
I simply removed his comment that refers to Iraq.
I think nominating Iraq here is really out of context.
I edited that little part and make a note.
I also asked to continue the discussion by PrivateMessage if he was going to discuss about my action.
Eventually you can contact the admins here, the one marked in red, if you feel that I was rude, it was not my aim and I do apologizes if I acted like that.
Also the Suggestion and Feedback is another good place to share your thoughts, not this thread.

As I said I still think that mentioning Iraq was not a good thing,
that's the reason of my action.
I'm not going to punish anyone, I was only trying to redirect discussions about my action to another place, PM or the suggestion and feedback forum, just to keep this thread clean.

I really appreciated your efforts here,
I really appreciated dagfinn posts.

If I was not clear about my action, I'm sorry but you could have used PM to ask clarifications about that.
Maybe I should have contacted you by PM too in the first place.


Peace.


p.s.
Sorry if my English is far from to be professional and is far from to be easy to read, but that's me.

[firepages]

I'd suggest that you provide a pointer to the "rules"

You had to agree to Sitepoint TOC when you first joined , the same as almost any other forum on the web.

I find Sitepoint one of the least moderated and open forums I goto , 99/100 when a mod mods something its valid (e.g whatever was modded was going to lead the thread wildy OT of make for flames) , dragging it out by pretending you don't understand only makes you look daft , take it like a man

[Azmo]

I came across a nice article by Gregor Hohpe today: The Dark Side of Encapsulation?

The core driver behind the separation of public interface and internal implementation is twofold:

* The interface allows the implementation to vary without users of the interface having to know about it.
* The interface can hide complex implementation details.

Hiding complex implementation details is likely the more challenging (and more abused) aspect of encapsulation. Too many times we see developers who purportedly abstracted the internals of their class be wrapping all class variables using getter/setter accessor methods. While this approach does provide a level of indirection, it hardly provides any abstraction or hiding of implementation internals. If each variable is accessible through a setter and getter method, the amount of knowledge that any developer has about the class internals is no less than is the class was simply exposing public properties. True encapsulation on the other hand happens when a complex implementation is wrapped with a much simpler public interface. In some cases, the interface can even present a programming model that is quite different from the internal implementation.

I couldn't have phrased it any better (I wouldn't even have come close). The rest of the article is worth reading, as well.

[dagfinn]

If you hold an apple in front of you, you're not hiding the apple. But if you hold the apple behind your back and say "I'm holding an apple behind my back", are you hiding it?

Probably not, but you could start lying at any time. That's the extent of "encapsulation" and "information hiding" provided by a getter method.

[seratonin]

If you hold an apple in front of you, you're not hiding the apple. But if you hold the apple behind your back and say "I'm holding an apple behind my back", are you hiding it?

Probably not, but you could start lying at any time. That's the extent of "encapsulation" and "information hiding" provided by a getter method.

I like that example...

JT