OOP: are getters/setters evil

[Klave]

---

Apil lang ko gud...

Comment comment lang...

Actually I really thought you wanted to add more parameters of something.

I was also trying to point out why they could say it could be evil.

But then like all systems nothing is perfect.
But then it isn't supposed to be perfect.
Systems were created with a sort of concept, with a goal in mind.

Setter/getters serves a purpose, also the many other concepts being introduced on a regular basis.

Gikan lang gyud ko ani...pero grabi jud ni ka samok kung report generation na...performance wise...fine-tuning...unya kung nagsugod pa ang project...so diha dapita evil siya.

Maayo ra ni gamiton while transaction pa...kay andam na tanan...

[yanong_banikanhon]

Mao gyud nay giingon nila nga 'it all depends', bay. In the wrong hands, mahimong evil ang getters/setters kay gigamit man sa sayop nga paagi. Pero kun gamiton siya subay sa iyang original nga purpose, getter/setter will make your code readable. Kun readable ang imong code, dali ra ning i-maintain.

Usa sa akong nahibal-an nga situation where getter/setter shines is when it is used in DTOs (Data Transfer Objects). In a domain-driven application, you have highly cohesive classes in your model. These classes contain only the data and behaviour related to themselves, no more, no less. So, if a class change, the impact to other classes is very minimum. While this approach works well in the business layer, it doesn't fit well in the presentation layer. Kasagaran man gud sa information nga ipakita sa presentation layer naggikan dili sa usa lamang ka object kundili sa nagkalambigit nga mga objects.

Atong himoong example kaning public profile page sa atong forum. Kun imong i-click ang 'View Public Profile' sa usa ka member, you will be redirected to a page which displays comprehensive information about that member. You will see his/her gender, interests, last activity, total posts, likes received/given, recent visitors and even visitor messages. This seemingly related information doesn't come from a single object in the business layer. The gender and interests may come from a Member object, the total posts and likes received/given may come from another two or more objects and so on.

To make the binding of these data to their respective controls in the public profile page easier, a MemberProfile DTO maybe constructed. The MemberProfile DTO is class with no methods but has all the information needed by the public profile page. The information is exposed as getters or public properties. If, instead of getters, public methods are being used, sagbot kaayong tan-awon ang code sa maong page kay mapuno man sa mga method calls to different objects.