No need to prove you wrong.
The general idea about reducing this is to provide object that give back values rather than passding data into object.
Yes this can be a bigger deal when looking at strongly typed languages, however the same rings true if you have assessors that when the internals of an object are changed they may need to be updated in hundreds of places in an application.
Setters/Getters in PHP or strongly typed languages usually bloat code, make assignments more difficult to understand and in many cases blow-up encapsulation. The encapsulation part can be argued as it can provide an opportunity to change the implementation behind the scenes without affecting the inputs to an object, but most often in php this is done very poorly, so in most cases it breaks encapsulation. Here is another article to chew on regarding the reduction of encapsulation using setter/getters [Doing it Wrong: Getters and Setters and a short blog about PHP getter/setters [URL="http://athos.blogs.balabit.com/2011/07/getter-setter-methods-vs-performance-in-php/"]Some thoughts on getter-setters](http://typicalprogrammer.com/?p=23)
Let's look at some of the reasons people use setters/getters in PHP:
- Frameworks often require them
- Dependency Injection
- Instance initialization
- Runtime instance state changes/inspection
- Data transfer objects
- ORM model object
What can happen if getters and setter are overused:
- Bloating the interface
- Increasing coupling
- Decreasing encapsulation
- Increased risk of misuse and call sequence errors
If Frameworks required them and you use a framework then it isn't the end of the world.
People see getter/setter in very many examples so they think that that is how things should be done. But you have a right to argue that it is not.
Constructor based injection is generally considered safer than setter/getters this includes when dependency injection is used in PHP. However you may run up against circular dependencies when doing constructor based dependency injection. In this case you will likely need to use a setter, but luckily this does not happen too often.
Essentially many will argue that public members are bad in OOP design. There is not much of a difference between a public member and a public setter.
The increase of coupling is a bad thing.
In PHP where we have lots of freedom, we can create instances based on configuration or constructor parameter and should be ready to go.
Getters/Setters make it a nightmare to reverse engineer an applications you are asked to take over.
You are right that we can reduce setter/getters in value objects, but we can must also ask ourselves if the data required by objects should really be part of an object and not just passed into it.
Setters and Getter are not always wrong, in some cases limited usage of setters/getters is ok, like:
- In cases where you create an instance of a class and still have to allow users to change its state.
- Data transfer object. Like when data is stored in an object and is sent over a transfer protocol like JSON, JSONP, or SOAP.
- In ORM model objects, as basically it is all the class does is to use setter and getter but makes sense in terms of datablase entries.
I don't think getters and setter are evil, I just think that we should stop and think what we are doing and are we creating more coupling than required or needlessly reducing information hiding/encapsulation?
Keep in mind that every time you want to refactor a class you will need to locate all the places that implement the getter and setters. This is true every time you add, remove, or change a member you need to check where and how it is set or get?
If you keep the instance variable of an object protect/private, we ensure that other classes don't depend on them and it gives us the flexibility to chaange a variable's type or implementation however we want without adversely affecting anything else.
So the idea is for an object to be responsible to compute somethin with its' own data and then return a result without needing getter/setters.
I guess I've flogged this horse to death.
Hope this stimulates ideas