CODEWITHSUNDEEP
javagetter-setter
Adesh
Adesh

Reputation: 947

How to choose your getters and setters in java

I have the payment class with only one local private variable - totalCost, as such totalCost also has a getter and setter methods. TotalCost is the only local variable because its the only one used in more than one method in the payment class. Should this class have more getters and setters? 

public class Payment {
    private int totalCost;

    public Payment(){
    }

    public int calculateItemcost(int itemQuantity, int itemPrice){
        return itemPrice * itemQuantity;

    public int calculateTotalcost(int itemCost){
        return totalCost = totalCost + itemCost;
    }


    public int calculateBalance(int clickedValue, int totalCost){
        return this.totalCost = totalCost - clickedValue;

    public int getTotalcost(){
        return this.totalCost;
    }    

    public void setTotalcost(int totalcost) {
        this.totalCost = totalcost;
    }
}

Upvotes: 2

Views: 422

Answers (4)

paxdiablo
paxdiablo

Reputation: 881093

Two guidelines I follow.

First, not necessarily all private data should be exposed via getters and setters, since some of them may be for internal use only.

Second, the getters and setters should provide an object view, not an implementation view.

For example, if your class has a hard-coded 10% tax rate on purchases (forgetting for now that hard-coding this is a bad idea), you could have a getter for the taxation component even though it's a calculated value rather than a private member. In addition, you may want to set the value based on the pre-tax price.

So, if the pre-tax value has 10% added on for the government vultures, something like:

public void setPreTax (int preTaxAmt) {
    totalCost = preTaxAmt * 11 / 10;
}
public int getTax (void) {
    return totalCost / 11;
}

I haven't bothered using floating point for the calculations since it's irrelevant to the discussion and you're already using int.

This object/implementation split is a good thing - you should design your API based on the information you want to provide to the clients of it, not based on internal details.

Upvotes: 2

Mik378
Mik378

Reputation: 22171

Do you know the law of Demeter?

It gathers some small guidelines to avoid loose coupling in your code.

Getters and setters are the elements leading to thight coupling between classes.

Why?

Because getters and setters informs you about the implementation of a class (its field especially) and its design.

Developer who ALWAYS code with creation of getters/setters systematically have misunderstood totally the notion of Object-Oriented programming.

Indeed, this leads to anemic domain model.

Thus, it forces client to implements the business logic themselves even though it isn't its role.

To put in a nutshell: In an application, 80% of getters and setters are unnecessary. Object-Oriented programming is about messages. You want a behaviour from an object, tell it ! Don't ask for information about its state in order to make your kitchen aside cause that would be typically a procedural way of coding. (Tell ! Don't Ask !!) and favor the non-respect of DRY (Don't repeat yourself).

Upvotes: 2

Lews Therin
Lews Therin

Reputation: 10995

Since you only have one field, which you already have getters and setters for. There is no point. Looks fine.

Although, refactor this: 

    public int calculateTotalcost(int itemCost){
        return totalCost = totalCost + itemCost;
    }

    public int calculateBalance(int clickedValue, int totalCost){
        return this.totalCost = totalCost - clickedValue;
    }

To call the setter. Example:

public int calculateTotalcost(int itemCost){
       setTotalCost(totalCost + itemCost);
       return getTotalCost();
    }

This way changes to totalCost is localized to the setTotalCost method.

Upvotes: 2

Juvanis
Juvanis

Reputation: 25950

You use getters for the fields that you might need to "get" in other classes, and setters for the fields that you might need to "set" in other classes. So before writing a getter/setter, think of your requirements.

Upvotes: 2

Related Questions