Should I call the getter method for methods in the same class?

Question

I started learning object-oriented programming and the instructor said that "getter" and "setter" functions are used to access and change certain private variables in another class.

For an assignment I was told to make a program that creates a deck of cards, prints it, shuffles it, and finally prints the shuffled deck. The assignment said I have to use good object-oriented principles.

I wrote this code and it works correctly

import java.util.Random;

public class CardDeck {

static String[] suitArray = {"Clubs", "Diamonds", "Hearts", "Spades"};

static String[] faceValue = {"1", "2", "3", "4", "5", "6", "7", "8", "9", "10","Jack", "Queen", "King"};

static String[] deckOfCards = new String[52];

public static void createDeck()
{
    int i = 0;
    for ( int j = 0; j < 4; j++ )  
    {
        for ( int k = 0; k < 13; k++ )
        {   
            getDeckOfCards()[i++] = getSuitArray()[j] + getFaceValue()[k];
        }
    }
    
    for(i = 0; i < 52; i++)
    {
        System.out.println(deckOfCards[i]);
    }
}

public static String[] getSuitArray() {
    return suitArray;
}

public static void setSuitArray(String[] suitArray) {
    CardDeck.suitArray = suitArray;
}

public static String[] getFaceValue() {
    return faceValue;
}

public static void setFaceValue(String[] faceValue) {
    CardDeck.faceValue = faceValue;
}

public static String[] getDeckOfCards() {
    return deckOfCards;
}

public static void setDeckOfCards(String[] deckOfCards) {
    CardDeck.deckOfCards = deckOfCards;
}
}

I have only included the portion the creates the deck.

is there harm in using the getter and setter methods? if not i'll keep them in case my instructor wants to see me use them

Generally speaking no, although a getter with logic could be used, one which filters or transforms the value it's returning. You don't *need* to remove the setters, you could remove them if you don't need them for anything, but your instructor may want to see them, or you may need them later. They're just extra unused code, nothing special about it. — Kayaman, Sep 17 '20 at 20:16
Does this answer your question? [Why use getters and setters/accessors?](https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors) — Curiosa Globunznik, Sep 17 '20 at 20:17
Looks like there are strongly disagreeing opinions around this questions. I personally tend not to use getters or setters for final variables, neither public nor private, for mutable ones I tend to use them always. I'm not prepared to defend those choices publicly, though. — Curiosa Globunznik, Sep 17 '20 at 20:37
Personally I like to use getter/setters when possible to avoid potential code refactoring if there ever crops up a need to adjust the value that is returned. This can be considered a code smell called [speculative generality](https://refactoring.guru/smells/speculative-generality) though (sort of... it's used but not necessarily useful), so your mileage may vary on how useful you find doing this. — Tim Hunter, Sep 17 '20 at 20:50
"The assignment said I have to use good object-oriented principles" - if this is true, then all those `static` keywords in the code need to be removed. — Gimby, Sep 18 '20 at 09:40
"The assignment said I have to use good object-oriented principles.". Then you probably want to model Cards as objects, the Suits as enum an maybe also the values as enum, and not expose your mutable(!) arrays to the caller, and you definitely don't want this all to be `static`. — Polygnome, Sep 22 '20 at 06:17

score 0 · Answer 1 · answered Sep 17 '20 at 21:03

This code isn't really object-oriented, because it simply manipulates some static variables.

If I gave an assignment like this, I would expect you to create a Card class, and create 52 or so instances with properties for their suite and rank set appropriately; perhaps the rank would be represented with both a numeric value and a human-friendly name. If you've learned about enum types, the suite would be represented as an enumerated value.

Further, a Deck class could be created with methods to shuffle the deck, and perhaps some static factory methods to build decks of different types. (For example, will the new deck include Jokers? Are aces high or low?)

Back to the original question, if an accessor can be overridden by a subclass, then you should use it, rather than direct field access, from within the class. In this case, I don't see a lot of need for extending a Card, so maybe your classes could be final. In other words, "Design and document classes for inheritance, or prohibit it."

No point of a `card` class if it has no functionality. – Above The Gods Sep 22 '20 at 04:48 — Above The Gods, Sep 22 '20 at 04:48

Above The Gods · Answer 2 · 2020-09-22T06:32:20.513

One of the fundamental concepts of object-oriented programming is encapsulation; that is, the implementation details of an object should remain hidden. It overlaps with the concept of abstraction. If you provide access to the inner workings of that object, either directly through public variables or indirectly through accessor methods (getter/setter), you are breaking encapsulation. This is known as a leaky abstraction.

Going back to your example: from the requirements alone, you only need one type: a deck of cards, or simply a interface deck. It should have two methods: deck.print() and deck.shuffle(). I would expect interface deck to know how to print and shuffle the cards by itself.

mumun · Answer 3 · 2020-09-22T07:17:40.880

0

I suggest you to create simple entities like real world examples for your case you can implement Card class for example then a Game or Manager class to organize Card Deck Operations logic.

edited Sep 22 '20 at 07:17

answered Sep 22 '20 at 06:19

mumun

51
1
8

Should I call the getter method for methods in the same class?

3 Answers3