OK, so now that we understand the most basic Java syntax it is time to learn how object-oriented design is implemented in Java.
The essential unit of article introduction in Java is the class. The class is often described as a blueprint for an object. It enables a software engineer to characterize the majority of the properties and techniques that inside characterize an article, the majority of the API strategies that remotely characterize an item, and the majority of the sentence structure vital for taking care of embodiment, legacy and polymorphism.
In its role as a blueprint, the class specifies what an actual object will look like. But it is not an object.
When a Java virtual machine creates an actual object from the class’ blueprint, it is said to create an “instance” (or instantiate) of the class. Thus, the blueprint is used to actually create an object which is stored in the computer’s memory. Once instantiated, an object will be able to utilize the methods and fields defined by its class.
|Many people use the following metaphors to describe the relationship between a class and an object: You can think of a class as a cookie cutter and an instance as an actual cookie. Similarly, you can think of a class as a blueprint of a house and an instance as an actual house.|
It is also important to know that more than one instance can be fabricated from the same class during the execution of a program. What’s more, each of these instances has its own copy of methods and fields so that over the life of the program each can grow independently.
Thus, for example, a Buton class might be used to instantiate two buttons in a program. Once instantiated, each Button has its own “Label” field and its own Background Color field. During the program, one button might be set to be Blue and to say: “Hello Cyberspace”. Another might be set to be red and say: “Hello Selena.” Both remain Button objects because they are based upon the Button class, but they gain unique features as uniquely instantiated objects.
|You can compare two objects to see if they are built from the same class by using the “instanceof” keyword such as in the following example:|
Abstract Classes Versus Interfaces
As a final note, I think it would be worthwhile to add a quick little section about abstract classes and interfaces. This section is based on a question I received last week along the lines of:
> when do you make a class Abstract?
> when do you define an interface?
> what is the difference between Abstract class
> and interface?
An abstract class is a special type of Java class that has the following characteristics:
- Abstract classes cannot be instantiated as objects.
- Abstract classes are usually used as superclasses from which to derive inherited classes that can be instantiated.
- Abstract classes usually contain base implementations of methods that all derived classes need or want.
I think the best way to understand an abstract class is by way of a real-world example.
Consider a Mammal class.
As you might recall from your years in primary school, all mammals share various methods and properties such as the fact that they are warm-blooded, maintain homeostasis, and have hair.
However, it would not exactly make sense to instantiate a mammal object from the mammal class.
Think about it, in the real world there really aren’t any plain, vanilla mammals. Rather, there are “animals that are of the mammal class by inheritance” such as dogs, whales, and people. But straight mammals…there aren’t any in nature.
(Rule 1: Abstract classes are not instantiated as objects).
The mammal is more of a category than a thing. It is a conceptual tool used to define characteristics shared by a set of objects. It is an organizational tool defining a hierarchy.
(Rule 2: Abstract classes are used from which to derive inherited classes)
However, Mammal is not simply an organizational tool. It has value in that it does do work. The Mammal class does define methods and properties.
As a result, inherited classes like dog, whale, and person do not need to do the work.
(Rule 3: Abstract classes usually contain base implementations of methods that all derived classes need or want.)
So what good are abstract classes to you as a programmer?
Well, they are really a convenience tool that you can use when you develop object libraries. Abstract classes give you the ability to define a class from which you will derive a set of classes when you want them all to inherit a set of functionality.
Thus they provide you a way to implement a set of methods and/or properties that all derived classes will inherit.
However, it is crucial to be clear that the abstract class itself is never used by itself.
I like the example that is given by Barry Boone in his Java 2 Exam Guide.
“Imagine a class called Transaction that is to be used in a home banking application. This class has two subclasses: Deposit and Withdrawal. It might not make sense to create an instance of Transaction; a customer doesn’t generically announce to the bank teller, ‘I want to make a transaction’, but rather ‘I want to make a deposit’ or ‘I want to make a withdrawal’.”
I think that Barry could go one step further. Not only does it not make sense to create a Transaction object, but it might also even be something that you want to discourage as the developer of an object library.
By declaring the class as abstract you force other programmers to maintain your sense of how the hierarchy works.
An interface is like an abstract class in that interfaces are not instantiated into objects. However, the similarity pretty much stops there.
Interfaces are not primarily concerned with defining a superclass from which to derive subclasses.
Similarly, interfaces do not contain base implementations to be used by subclasses.
Instead, an interface defines a set of “unimplemented” methods that some other object must implement in order to claim the title “official implementor of the interface”
Interfaces are essentially contracts that specify that any object that claims to implement the interface agrees to implement the set of methods defined by the interface.
Once an implementor has implemented the methods, any other object in the application can trust that the implementor has in fact implemented the methods defined by the interface.
Like abstract classes, interfaces are constructs to help programmers keep object libraries controlled and to enforce standardization on further development by other programmers. They are there to help you maintain high coding standards.
As we said earlier in our discussion of object-oriented programing, methods are the verbs of objects. Methods, like subroutines in procedural-oriented programming, are the basic unit of functionality of an object. They are a body of executable code contained within a class which can be used to effect an instantiated object of the class.
Methods consist of the following components:
- A method name
- A list of inputs which may be empty
- A return type which may be “void” if the method returns nothing
- The code to perform some action
|Actually, some methods, such as abstract methods, do not require the executable code. Abstract methods are used as interfaces to help define a skeleton of functionality but leave the fleshing out to another.|
Consider the following code snippet:
int add(int a, int b)
In this case, we have created a method which adds two integers passed to it as arguments and then returns the result. The method is named “add” and might be used in your code with a line such as the following in which mySum is set to “7”:
int mySum = add(3, 4)
|Note that you can only define methods within the body of a class definition so the above code alone would not work unless you made it part of a class.|