The major advantages to Object Orientation are encapsulation and inheritance.
We have already discussed encapsulation when we discussed the class Tank. An object or an instance of class tank not only has the content of a tank held inside it, it has the methods that operate on or query the content as well. An application that creates tank objects can be assured that they will never be in a bad state by having contents that are below zero or over capacity. Through the exception facility in java, applications can pinpoint problems more rapidly.
We first talked about Inheritance when we discussed the exception handling features of Java. Recall that in Java we create exception classes such as TankOverFlowException that are subclasses of a super class called Exception. It is not hard to think of why super classes such as Exception are useful. For one thing, it provides uniformity to the way we handle abnormal cases. Any of our methods that throw an exception force the application that invokes them to catch that exception. This is something that if the application programmer forgets to deal with, he or she will be reminded with a compilation error. Since all exceptions are designed in similar fashion, we have a sense of familiarity when we look at new classes that throw them. That feeling of familiarity is part of the draw for object orientation, it prevails all over the place.
displayTank is a subclass of the Tank class. As the class
header indicates, displayTank extends Tank (public class displayTank extends Tank).
displayTank simply adds a new functionality to the Tank class that enable us to display the Tank at some coordinate of a canvas. You should notice that displayTank does not extend canvas; thats why it has a display method instead of a paint method that the trafficLight class had in Assignment #1. The display method will need a Graphic object as a parameter to draw on, but, unlike the paint method it must be called explicitly. You will see later that it is called from the tankApplet's paint method.
The key point to be made here is that all fields and methods of Tank are inherited by displayTank as if we had literally copied them from Tank.
The call to super in the displayTank's constructor is for the invokation of the constructor in Tank, setting of the content_ to zero in Tank gets performed because of this call. Other than that, the constructor sets the x and y coordinates of the tank.
The display as mentioned before draws the tank on the applet's canvas.
snapshot of the tankApplet shows the components displayed. Four buttons on top, a tank in the middle, and a textField at the bottom. tankApplet introduces a different layout manager as well, BorderLayout enable us to place components at borders of the applet's canvas (i.e. North, South, etc.). This applet is also used to introduce the use of Panel that enable us to group components together. In this applet, the four buttons are placed in a panel and the panel is placed at the north boarder of the applet's canvas.
Of course, t, our tank, is not added in the init method like other components because it is not one. If you look at the paint method here you will notice the call to t's dislplay method; this is what I ment earlier about the need for an explicit call to the display method in order to draw the tank. The only safe place to call the display method is from the paint method of an applet or some other Canvas subclass.
The action method handles the button clicks and displays messages
in the textField. Notice that t.add(amt) or
t.remove(amt) calls are made as if t is just a regular
tank; keep in mind that displayTank "is a" Tank.
You will develop a parkingLotObserver class that is designed to graphically display the status of a parkingLot. parkingLotObserver is different from displayTank discussed earlier; unlike displayTank which "is a" a tank, it is NOT a parkingLot. When you look at it carefully, you will notice that it "has a" parkingLot that it is designed to observe. We'll dicuss the components involved in building such an observer in Assignment #2.
There are numerous application for either of these data structures. For example, you issue a print command on a multi-user system, is it not possible for other people to also issue the same command? A queue allows us to process these print requests in order. An example of where a stack is useful is in implementation of a preemption mechanism for resources. Lets consider a single cpu system with multiple processes competing for access to cpu. Often we assign priority to these requests. Suppose we have 4 priority levels, 1 through 4. Now, assume a process with the lowest priority (1) takes over the cpu and is processed for a while. Suppose that a new process comes along with priority 2, it preempts the first process by taking over the cpu, but the system can't throw away the first process, so it is put on a stack. Consider a process with priority 3 coming along and preempting the process with priority 2, guess what happens to the preempted process? It gets put on the stack too, but because of the behavior of the stack, when the priority 3 process is done, it is a "no brainer" as to who should be picked from the ones preempted. The one with the highest priority will be at the top and it is the one we take off and resume processing of since the data structure is a stack.
There are variety of implementations for stacks and queues. For a queue,
we can define an array and put each element that comes in in the next
available spot. When it is time to take an element off, we take the element
in cell zero and move the rest back.
We can implement a circular queue where we keep two
indexes one to the front of the queue and one to the back. In such a
implementation, we don't move everything back when an element is taken off--we
just move our index over to the next cell. But, its more complicated, as the
name indicates when we get to the last spot in the array we circle back to
the beginning. This makes adding and removing a little more complex, but
the advantage is in that you don't have to move everything back, each time
that you remove an element. The last implementation is a linked list. If
we don't know how much room we need to put aside for our queue, we
implement it with a linked list that can grow indefinitely!
Here is a stack and a queue class that hold Objects.
Note that they both throw Exception objects when dealing with putting elements in when there is no room
or removing elements when there is nothing to remove.
public class Stack {
protected int size_;
protected int top_=-1;
protected Object l_[];
public Stack (int size) {
size_ = size;
l_=new Object[size];
}
public boolean empty() {
return top_ == -1;
}
public boolean full(){
return top_ == size_-1;
}
public Object pop() throws Exception {
if (empty()) throw new Exception();
top_--;
return l_[top_+1];
}
public void push(Object val) throws Exception {
if (full()) throw new Exception();
l_[++top_]=val;
}
}
public class Queue {
private int size_;
private int last_=-1;
private Object q_[];
public Queue (int size) {
size_ = size;
q_=new Object[size_];
}
public boolean empty() {
return last_ == -1;
}
public boolean full() {
return last_ == size_-1;
}
public void enqueue(Object x) throws Exception {
if (last_ == size_ - 1) throw new Exception();
q_[++last_]=x;
}
public void dequeue() throws Exception {
if (last_ == -1) throw new Exception();
for (int i=0;i<last_;i++) q_[i]=q_[i+1]; //shift elements back by 1 cell.
}
public Object peek() throws Exception {
if (last_ == -1) throw new Exception();
return q_[0];
}
}
