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.
The Boolean methods, named after the logician George Boole, are so-called because the values they return are ‘true’ and ‘false’, which are represented by the numbers 1 and 0 in the two-valued Boolean number system all computers use.
The ToString() methods convert an integer data type to a corresponding string of letters.
For instance, when provided the number 2, the rankToString() method returns the string ‘Two’.
Common best practice for real-world Java applications places the main method in its own, separate Main class, so we’ll leave that method aside for now.
In short, the Card class above consists of two fields, representing common properties of a card object, a makeshift identification of the card ranks and suits with integers that makes them easier to functionally manipulate, and a set of methods that perform various operations on the card’s fields.
Related classes are bundled together into a package, which are to Classes what a file folder is to files.
3 OOP Objects as monadsThus, object-oriented programming classes are integrated into a larger whole, and have methods that act reflexively on their states, where these methods may treat the things they act on either in accordance with the nature of what they represent or in accordance with their nature as objects in an program.
Because of the first condition, classes themselves serve as abstract parts in an abstract whole.
When a program using these classes is run, objects which are instances of these classes are created and their methods are used in accordance with user input and the instructions in the code itself.
Because of this, objects can, in turn, exist in other objects.
Philosophy has a name for an object which may exist in another object, has behavior which is reflexive upon its own state, and responds to the behavior of other objects through its own spontaneous behavior, such that all these beings exist as part of a harmoniously working whole: a monad.
The term goes back to Gottfried Leibniz, who introduced the concept to provide a unified solution to the problems involved in explaining both interactions between different bodies and the relation of the body to the soul.
On Leibniz’s account, objects don’t genuinely change each other’s states.
Instead, God so closely harmonized these various objects in their nature at the beginning of creation that a change in one object would automatically result in a corresponding, albeit spontaneous, change in others.
Object-oriented objects act on their own states, exist as parts in a harmonious whole and are all ordered by one dominant method called the main method, just as Leibniz’s monads act reflexively on themselves in a harmonious world ordered perfectly by God from creation.
4 ConclusionThough object-oriented programming objects are often presented as being strictly analogous to real-world objects, this analogy breaks down fairly quickly.
While OOP fields are similar to the static properties of real-world objects, the dynamic behavior of OOP objects is fundamentally different from that of real-world objects: OOP methods don’t explicitly distinguish instances of classes as representations from those same objects as instances of code, and the methods bundled together in a class are bundled with that class (rather than another) because of the manner in which they reflect on, utilize, or otherwise manipulate the object’s more basic states.
OOP classes are parts in a whole package, and the methods listed for a given class will depend on the role it plays in that whole (or a similar one).
When a program is run, the exact order in which various objects act is given by a master method called the main method, usually set off in its own class.
In these ways, objects which instantiate classes in packages are closer to the philosophical account of objects found in Leibniz’s account of monads as parts of a harmonious world which act reflexively on their own states in a manner God coordinates, than they are to objects as commonly understood.
Originally published at http://jacobarchambault.
com on May 11, 2019.
.