OOP: are getters/setters evil

[fixyourself]

ops, soryy implementing the interface would expose public methods.. haha

[yanong_banikanhon]

Kining ato, bay, exchange2x man lang ni og idea. Lingaw pud kog basa sa imong mga reply.

Pananglit kaning BarGraph class bay, modawat og double values unya iya dayong i-draw ang graph representation sa mga values sa screen.

Sa ani man gud nga case, morag paminaw nako, kinahanglan gihapon sa Money class ang getAmount (setter or public method) that will return a native type (int or double).

Naa pay lain nga case that I think our Money class cannot handle. Suppose we want to get the percentage of the actual customers' balance against the bank's maintaining balance.

The formula could be:

Percentage = (actual balance/maintaining balance) * 100

In this case, the result is no longer a money object, but a numeric representation of percentage.

The code below will NOT work:

Money //class
{

public static Money getBalancePercentage(Money maintainingBalance)
{
   double result = (this.getBalance() / maintainingBalance) * 100
   // it is wrong to instantiate a money object and return it to the caller
   // simply because 'result' is not a money instance but a percentage instance 
}
}

This code might work:

Money //class
{

public static double getBalancePercentage(Money maintainingBalance)
{
   double result = (this.getBalance() / maintainingBalance) * 100
   return result;
}
}

But then, if you change the return type of the method from double to float, for example, we have no choice but to update all the codes which call the getBalancePercentage method. On top of that, the getBalancePercentage has nothing to do with the money class. It should not be in the money class in the first place. But then, if you put it somewhere else, you need to access the getAmount setter/public method of the money class. If the signature of getAmount changes, we need to change the calling codes as well. In those cases, updates are unavoidable bisan pag public method or getter atong gamiton.

Just my two cents, though.

[fixyourself]

Definitely right, since we are now talking about percentage. Unless we are to provide another class that will handle percentage, but that would make the issue more complicated.

The simpler the solution, the better. Depending on the problem, setters/getters are not evil, unless used in the wrong way.

Makes me wonder now if ang TS nakasabot ba sa atong talk.. haha.. good talk

enough for now, have to go home.. lol, salamat dai bai, kita rai nka puno dire.. lol..

[fixyourself]

ps: for the record

added @yanong_banikanhon to my respect list.

the forum needs people like him, i got 2 now, @kamahak and you.. salamat bai..

[fixyourself]

bai @yanong_banikanhon, i tried to solve katong problem imong gi ingon bahin sa graphs without setting a public accessor, anyways, heres the code in C#, as proposed i used an interface (exposed a property/method but for graphic purposes only). Also about the percentage issue, you're right because percentage is not money, always man ta sure nga ang percentage is 00.000 (double).

so it is safer to implement in our example class

double getPercentage(Money maintainingBalance);
or
Percentage getPercentage(Money maintaininBalance);
if we have a percentage class which handles percentage, pero ai nlang na.. lol..

    public class Money : IGraphElementValue, IComparable
    {
        private double m_amount = 0;

        public Money()
        {
            m_amount = 0;
        }

        public Money(double amount)
        {
            m_amount = amount;
        }

        public void IncreaseBy(Money money)
        {
            m_amount += money.m_amount;    
        }

        public void DecreaseBy(Money money)
        {
            m_amount -= money.m_amount;
        }

        public Money Difference(Money money)
        {
            double result = m_amount - money.m_amount;
            return new Money(result);
        }

        public Money Percent(double percent)
        { 
            double result = m_amount * (percent / 100);
            return new Money(result);
        }

        public int CompareTo(Money money)
        {
            return m_amount.CompareTo(money.m_amount);
        }

        int IComparable.CompareTo(object item)
        {
            return CompareTo(item as Money);
        }

        public override string ToString()
        {
            return m_amount.ToString();
        }

        public string ToString(string format)
        {
            return m_amount.ToString(format);
        }

        //operator overloads
        public static Money operator +(Money m1, Money m2)
        {
            return new Money(m1.m_amount + m2.m_amount);
        }

        public static Money operator -(Money m1, Money m2)
        {
            return new Money(m1.m_amount - m2.m_amount);
        }

        public static Money operator *(Money m1, Money m2)
        {
            return new Money(m1.m_amount * m2.m_amount);
        }

        public static Money operator /(Money m1, Money m2)
        {
            return new Money(m1.m_amount / m2.m_amount);
        }

        public static Money operator +(Money m1, int i1)
        {
            return new Money(m1.m_amount + i1);
        }

        public static Money operator +(Money m1, double d1)
        {
            return new Money(m1.m_amount + d1);
        }

        public static Money operator +(int i1, Money m1)
        {
            return new Money(i1 + m1.m_amount);
        }

        public static Money operator +(double d1, Money m1)
        {
            return new Money(d1 + m1.m_amount);
        }
        //continue the overload....

        //Util Methods
        public static readonly Money ZERO = new Money();

        public static Money Average(params Money[] moneys)
        {
            double total = 0;
            foreach (Money money in moneys)
                total += money.m_amount;
            return new Money(total / moneys.Length);
        }

        public static Money Parse(string value)
        {
            try
            {
                double val = double.Parse(value);
                return new Money(val);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

        //Graphing Interface
        object IGraphElementValue.Value
        {
            get
            {
                return m_amount;
            }
        }

        string IGraphElementValue.Display()
        {
            return m_amount.ToString();
        }

        string IGraphElementValue.Display(string format)
        {
            return m_amount.ToString(format);
        }

        
    }

    interface IGraphElementValue
    {
        object Value { get; }
        string Display();
        string Display(string format);
    }

    public class Customer 
    {
        public Name CustomerName;
        public Money CustomerBalance;

        public Customer(string customerCode)
        { 
            //get data
            string lastname = "LastName" + customerCode;
            string firstName = "FirstName" + customerCode;
            double money = 100;
            //
            CustomerBalance = new Money(money);
            CustomerName = new Name(lastname, firstName);
        }
    }

    public class CustomerGrapher : List<Customer>
    {

        public void DisplayGraph()
        { 
            foreach(Customer customer in this)
            {
                IGraphElementValue graphValue = customer.CustomerBalance as IGraphElementValue;

                Console.WriteLine(string.Format("{0} - {1}", customer.CustomerName.ToString(),
                    graphValue.Display()));
            }
        }

    }

[-_-]

wow that was a lot of discussion, good to hear na daghan sad diay maayo dre da, im glad that i could listen to your discussion guys . cheers

[yanong_banikanhon]

OT:

@fixyourself: makita gyud ang dugo sa pagka-programmer, bay da. dili makatulog kun dili ma-solve ang usa ka problem.

[fixyourself]

lol, haha.. mao, ambot i guess tnan man gyud guro programmer mag huna2x gyapon bsta naay di masulbad bsag naa nas balay.. problem solver man gyud ang purpose sa programmer hehe

[Klave]

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?

First of all...setter and getter don't get changed in between...

private Double balance;

public Double getBalance(){
   return balance;
}

public void setBalance(Double balance){
 this.balance = balance;
}

Setter/Getters are not supposed to be changed...
They define your object, but it is kept empty with no logic inside...
If the parameters get changed, like Double to String...that would be a major change...and the one making the specs wasn't paying attention.
you cannot change the parameters...
you cannot also add some logic inside the function...
the code is stricly just that above.
They are sort of evil as your project is bound to your objects...
but then since they are objects and you usually pair this style of programming with a Persistence framework. They become easier to work with, and if done properly, you don't think of the back end anymore. As you only think of them as objects...parent, children and back references they are all objects...thus if using OOP, taking full advantage of the system.

[fixyourself]

First of all...setter and getter don't get changed in between...

private Double balance;

public Double getBalance(){
   return balance;
}

public void setBalance(Double balance){
 this.balance = balance;
}

Setter/Getters are not supposed to be changed...
They define your object, but it is kept empty with no logic inside...
If the parameters get changed, like Double to String...that would be a major change...and the one making the specs wasn't paying attention.
you cannot change the parameters...
you cannot also add some logic inside the function...
the code is stricly just that above.
They are sort of evil as your project is bound to your objects...
but then since they are objects and you usually pair this style of programming with a Persistence framework. They become easier to work with, and if done properly, you don't think of the back end anymore. As you only think of them as objects...parent, children and back references they are all objects...thus if using OOP, taking full advantage of the system.

lol, obvious man.. haha, nag lalis gani mi..