In previous posts, we established the following:

• Real-world objects have states and behavior. Objects in object-oriented programming (OOP) have analogues to these called fields and methods.
• The fields of object-oriented objects parallel the states of real-world objects more or less faithfully. But the parallel between the methods of object-oriented objects and the behavior of real-world objects breaks down relatively quickly, for two reasons:
  • The first is that more often than not, the methods of object oriented objects do not represent things the object can do, but things that can be done to the object.
  • Second, objects in object-oriented languages don’t neatly distinguish between methods that act on the object in accordance with the nature of the object it is intended to represent (e.g. as a ‘pedal’ method might work on a bicycle object), and methods that act on the object precisely as a bundle of code within a computer program. Colloquially, one might say there is a blending together of larger reality that the object is meant to represent with that which it is, as a piece of code, actually a part of.

What are OOP objects?

What, then, are OOP Objects? Better yet, what is it that makes such objects unified in some way, rather than random bundles of code? And accordingly, what is it that makes some OOP objects better conform to the ideal of an OOP object than others?

To answer this question, let’s look at one more example:

public class Card {
    private final int rank;
    private final int suit;

    // Kinds of suits
    public final static int DIAMONDS = 1;
    public final static int CLUBS    = 2;
    public final static int HEARTS   = 3;
    public final static int SPADES   = 4;

    // Kinds of ranks
    public final static int ACE   = 1;
    public final static int DEUCE = 2;
    public final static int THREE = 3;
    public final static int FOUR  = 4;
    public final static int FIVE  = 5;
    public final static int SIX   = 6;
    public final static int SEVEN = 7;
    public final static int EIGHT = 8;
    public final static int NINE  = 9;
    public final static int TEN   = 10;
    public final static int JACK  = 11;
    public final static int QUEEN = 12;
    public final static int KING  = 13;

    public Card(int rank, int suit) {
        assert isValidRank(rank);
        assert isValidSuit(suit);
        this.rank = rank;
        this.suit = suit;
    }

    public int getSuit() {
        return suit;
    }

    public int getRank() {
        return rank;
    }

    public static boolean isValidRank(int rank) {
        return ACE <= rank && rank <= KING;
    }

    public static boolean isValidSuit(int suit) {
        return DIAMONDS <= suit && suit <= SPADES;
    }

    public static String rankToString(int rank) {
        switch (rank) {
        case ACE:
            return "Ace";
        case DEUCE:
            return "Deuce";
        case THREE:
            return "Three";
        case FOUR:
            return "Four";
        case FIVE:
            return "Five";
        case SIX:
            return "Six";
        case SEVEN:
            return "Seven";
        case EIGHT:
            return "Eight";
        case NINE:
            return "Nine";
        case TEN:
            return "Ten";
        case JACK:
            return "Jack";
        case QUEEN:
            return "Queen";
        case KING:
            return "King";
        default:
            //Handle an illegal argument.  There are generally two
            //ways to handle invalid arguments, throwing an exception
            //(see the section on Handling Exceptions) or return null
            return null;
        }    
    }
    
    public static String suitToString(int suit) {
        switch (suit) {
        case DIAMONDS:
            return "Diamonds";
        case CLUBS:
            return "Clubs";
        case HEARTS:
            return "Hearts";
        case SPADES:
            return "Spades";
        default:
            return null;
        }    
    }

    public static void main(String[] args) {
    	
    	// must run program with -ea flag (java -ea ..) to
    	// use assert statements
        assert rankToString(ACE) == "Ace";
        assert rankToString(DEUCE) == "Deuce";
        assert rankToString(THREE) == "Three";
        assert rankToString(FOUR) == "Four";
        assert rankToString(FIVE) == "Five";
        assert rankToString(SIX) == "Six";
        assert rankToString(SEVEN) == "Seven";
        assert rankToString(EIGHT) == "Eight";
        assert rankToString(NINE) == "Nine";
        assert rankToString(TEN) == "Ten";
        assert rankToString(JACK) == "Jack";
        assert rankToString(QUEEN) == "Queen";
        assert rankToString(KING) == "King";

        assert suitToString(DIAMONDS) == "Diamonds";
        assert suitToString(CLUBS) == "Clubs";
        assert suitToString(HEARTS) == "Hearts";
        assert suitToString(SPADES) == "Spades";

    }
}

The above provides an example of a Card class, again taken from Oracle’s Java tutorials. Let’s walk through it.

After the name of the class and an initial curly brace, two fields are declared: rank and suit. After this follow all the kinds of suits, then the kinds of ranks. This is followed by a special kind of method, called a constructor, which may be used by other objects to generate an instance of the Card class, then a pair of methods getSuit() and getRank(), which respectively provide, or return, the value of the suit and rank of a card object to whatever object makes use of, or calls, these methods. This pair of functions belongs to a larger class of methods called getters, whose naming and functionality follow a longstanding coding convention. This is followed by two boolean methods, isValidRank() and isValidSuit(), the methods suitToString() and rankToString(), and the main method.

Tomorrow, I’ll continue to explain how to understand objects and classes in object-oriented programming.