When we create methods to do things, usually we manipulate data. When we work with static methods, this is done by taking in a set of variables, each with a fixed data type, and doing something with them. For instance:
public static boolean intEquals(int a, int b) {
return a == b;
}
Creating static methods separate from any data works very well in cases like these, where there is
not any association between either of the int
s, and when we are working with primitives. However,
what if we want to create methods to manipulate more complicated data types, like String
s? Here is
what we could do: rather than having methods be freestanding, let's associate them with the data
type. In this class, more complicated data types are defined by classes. Ah, that's why Java
makes you type class
at the beginning of each file. String
is actually a class, built right into
Java. These classes contain both variables that comprise the data stored by any instance of this
class (more on instances in a bit) as well as methods that work directly on the variables contained
in this class.
Java's built-in String
class is really just an array of characters with all sorts of methods that
deal with this char array. It looks something like this:
public class String {
private char[] content;
public String(char[] newContent) {
content = newContent;
}
public int length() {
return content.length;
}
// plus much, much more...
}
As you can see, we now define methods that directly operate on the data within this class. When we
create variables with data type of a certain class, we create what are known as objects. In this
case, when we create String
variables, these are String
objects.
Object-oriented programming is when we create more sophisticated data types from the primitive data types provided to us, and instead of creating static methods to deal with these sophisticated data types, we incorporate them directly into the sophisticated data type as an instance method. But, we aren't dealing with all of the variables that are this sophisticated data type, just one instance of it. That's why we have objects. They are instances of this class!
The fundamental connection between classes and objects: Objects are instances of classes.
What's a real life connection to classes and objects?
Amazon has millions and millions of shipping boxes. They are all pretty similar. Let's just say they are all the same design. We'd say all these shipping boxes are of the same class because they are comprised of the same things and the same functionality. You can open them, close them, tape them, rip them, incinerate them, etc.; no two boxes have different functionality. (Well, that is, until you rip them or burn them, but then they aren't really boxes anymore.) On the other hand, each box would be considered objects in this case. These actions happen to one box at a time. What happens to one box is independent of what happens to other boxes, even though they share the same possible actions and the same characteristics. That is why when we call methods defined in a class, it only affects that specific object.
Back to top© 2019–2024 Jeffrey Wang. All rights reserved.
In loving memory of Haskell, 19??-2001.