OOP: are getters/setters evil

[-_-]

---

nag himo ko ug centralized na getter/setter since murag balik balik ra jud sya, non-DRY. na discover nako ni Typical Programmer - Doing it wrong: getters and setters and this link also More on getters and setters - JavaWorld, any thought on this?

[silent-kill]

most likely kong ga balik balik imong mga getters and setters you have an incorrect class relationship.

if you you use proper inheritance, di nana siya mag balik balik.

[fixyourself]

Another thread which tackles topics on design patterns and architecture, why not create a general thread for Architecture/Design Patterns. You could post links which leads to information resources, like the links above, plus your views and opinions, tutorials.. etc. Design patterns is a huge topic, i think its better if we have a general thread for this. (correct me if this thread existed)

@-_- shoot.

[-_-]

Another thread which tackles topics on design patterns and architecture, why not create a general thread for Architecture/Design Patterns. You could post links which leads to information resources, like the links above, plus your views and opinions, tutorials.. etc. Design patterns is a huge topic, i think its better if we have a general thread for this. (correct me if this thread existed)

@-_- shoot.

I think wala ko ka kita ug lain na thread

Off topic: unsay pasabot nimo sa "@-_- shoot" hehe

[neigyl_noval]

This is some of the reasons why C# has properties as their feature.

[fixyourself]

This is some of the reasons why C# has properties as their feature.

How does .net languages property feature differ from setters and getters? lol, it is still setters/getters, in fact through reflection you could see that internally the property is also implemented as a method in this pattern set_PropertyName, get_PropertyName.

eg.

public string Currency
{
  get;
  set;
}

//it is implemented like this
string get_Currency();
void set_Currency(string value);

[neigyl_noval]

How does .net languages property feature differ from setters and getters? lol, it is still setters/getters, in fact through reflection you could see that internally the property is also implemented as a method in this pattern set_PropertyName, get_PropertyName.

eg.

public string Currency
{
  get;
  set;
}

//it is implemented like this
string get_Currency();
void set_Currency(string value);

Very correct. Properties are of course getters and setters. But I guess the concern of TS is the excessive use, or misuse, or unnecessary getters and setters, or waste effects of getters and setters, as illustrated on the link he has given.

[prince04]

if nag balik2 na imuhang getters ug setters,
mas better mag create nlng ka ug abstract class wherein ang sulod kay ang mga common properties then i extend lng nimu...

pero ang kaning getters and setters is dicouraged jud bsta android ang stryaan...

[fixyourself]

if nag balik2 na imuhang getters ug setters,
mas better mag create nlng ka ug abstract class wherein ang sulod kay ang mga common properties then i extend lng nimu...

pero ang kaning getters and setters is dicouraged jud bsta android ang stryaan...

not just in android.. one of the reason why evil ang setters/getters is you are exposing an objects implementation to other classes. If you are to change the object implementation, this would also require all other classes which uses the object to be changed. Lisura e explain oi ani nlng.. for example.

Class Customer
{ 
  public Customer(string customerCode);
  public int getBalance();
  public void setBalance(int balance);
}

Class UserClass1
{
   private PrintCustomerBalance()
   {
     Customer cust = new Customer("CUST01");
     int bal = cust.getBalance();
     print(bal.toString());
   }

   private SetCustomerBalance(int balance)
   {
     Customer cust = new Customer("CUST01");
     cust.setBalance(balance);
   }

}

now if i have to change the implementation of getBalance and setBalance as

public double getBalance();
public void setBalance(double balance);

What do you think would happen?

[yanong_banikanhon]

not just in android.. one of the reason why evil ang setters/getters is you are exposing an objects implementation to other classes. If you are to change the object implementation, this would also require all other classes which uses the object to be changed.

Correction lang gamay, boss. When you put a setter/getter in your class, you are NOT exposing an IMPLEMENTATION to other classes. In fact, you are exposing an interface (i.e. a safe, well-known point of interaction to outside classes). Any other object can happily call a getter from an object of your class without thinking how your class calculates the value of that property.

Extending your example, imagine that the logic that calculates the customer's balance is placed in a separate private method and you exposed a getter which just call that private method and return the result to an object of UserClass1.

Class Customer
{ 
  private string _customerCode
  public Customer(string customerCode)
  {
     _customerCode = customerCode;
  }

  public int getBalance( return CalculateBalance(); );

  private int CalculateBalance()
  {
    // complex balance calculation logic goes here
  }
}

Class UserClass1
{
   private PrintCustomerBalance()
   {
     Customer cust = new Customer("CUST01");
     int bal = cust.getBalance();
     print(bal.toString());
   }
}

What did we achieve? We achieved encapsulation. We encapsulated the logic that calculates the customer's balance (which is complex and may change based on the ever-changing business rule) by putting it inside a private method which nobody but the Customer class can access.

If the business rule for calculating the customer's balance changes, you only need to change the private method. The getter will remain the same. And any object of your UserClass1 will still work. This happens because you exposed a balance getter and hide the balance implementation inside the Customer class.

One thing to note, in your previous example, you exposed a setter for balance and then assigned a value to it inside the UserClass1. I feel it is a code smell. Calculation of the balance should be done inside the customer class, not in the client classes (i.e, UserClass1).

Another anti-pattern is exposing a getter/setter for all the instant fields of the class. Only expose a getter or a setter if and only if there is a real requirement to make that information visible/accessible to other classes.