Object Oriented design requires identification of objects, their relationships and communications. Use of nouns and verbs found in specifications in determining objects, their state and methods is one of the techniques employed in this process. It is critical to design clean and coherent classes of objects that encapsulate a state and a set of methods that operate on that state. Hiding the details from the other components of a system is critical here. Objects must act as black boxes wherever we use them. A class must be highly cohesive, all of its pieces, be it, the elements that constitute the state of its objects, or its methods must fit together perfectly--they must make sense. Classes must be loosely coupled, the communication between objects must be clear and minimal.
Probably, the single most important difference between the traditional top-down approach to design and object oriented design is in the level of software reuse. A good Object designer looks for existing classes of objects. He/she employs inheritance to extend classes to make them meet his/her needs, never reinventing the wheel. Java Package Documentation provide a good example of object classification and frameworks. You will use a small percentage of Java classes, but browsing through them is helpful.
Testing of all parts with drivers and stubs must occur as the classes are being developed. But, integrating the various components and testing their interaction is critical here. The sensitive components of a system may need to go through a rigorous mathematical proof to ensure their correctness.
Let users use it. They may have already played with a prototype, but this is for real. Todays industry seems to advocate alpha and beta releases. Although there are some advantages to this, broad-based releases of incomplete with most likely incorrect components does not make sense to me! But, its the way things are today.
Make corrections, make additions, and may be even redesign some parts.
An applet is a small embeddable Java program. In our course, we will set up HTML files that will run our applets. What you will write are subclasses of the Applet class. The Applet class is a subclass of Panel which in turn is a subclass of Container, which in turn is a subclass of Component, which in turn is a subclass of the Object class. Component implements an interface named ImageObserver. Interfaces provide specification for behavior that are adopted and implemented by classes.
Why list the class hierarchy leading to the Applet class? Knowing the class hierarchy in an object oriented framework is not always necessary, but at times useful. When considering the big picture, as discussed earlier, learning to become a class user is as important as learning to develop algorithms. Traversing Java API for the right class or method is an important part of programming with Java and it is best that you get used to it now.
For the most part, when developing applets, you will have examples to guide you on what methods to write. However, if you decide to find out more about any of those methods, you will most likely look much deeper than just the Applet class for its specification in Java API. The functionality provided for applets is not fully specified at that level, much of it is defined in the classes leading to it. For example, if you are interested in knowing what the specification for the paint(Graphics) method is, you would have to look at the Component class. But, how do you track that method down? First of all, there are several ways to do it, but here I'll describe just one way. Start from the Java's Packages page and take the path to java.applet package. From there, follow the link to Applet. Once you look through the Applet class and notice that the paint method is not there, you can move up to the Panel class and continue this process until you locate paint() in Component.
Java is rich with classes that enable you to do graphics and many other neat things. For most students, the most appealing part of Java is its applets and the fact that it can be transported across the internet and run on any platform. We will begin by looking at a Hello World example. I wrote a couple of simpler Applets first, if you like to check them out too: First Hello World and Second Hello World.
This is a detailed discussion of the Third Hello World Applet.
public class hello3 extends Applet means that the class name is
hello3 and it is a subclass of the Applet class.
The variable declarations at the top of this class work the same way as they do with other classes in Java--they are available in all methods of hello3.
protected Font hello_font; is the declaration
of hello_font which will later get constructed in
the init
method. This is the statement that constructs hello_font:
hello_font=new Font("Helvetica",Font.BOLD,48);. Note that
the arguments for the constructor are the Font name, its style, and size.
In the following pair of statements, we first set the font to
hello_font for our applet's Graphics object
(all applets have one), then we draw the string "HELLO WORLD" using that font.
g.setFont(hello_font);
g.drawString("HELLO WORLD",40,110);
protected Button bye_button; is the declaration
of bye_button which will also get constructed in the init
method. The following sequence of statements construct the bye_button and
set its front and background colors:
bye_button = new Button("Bye");
bye_button.setForeground(Color.black);
bye_button.setBackground(Color.lightGray);
The statement that follows these this.add(bye_button); is
designed to include the button in the drawing area associated with the
applet.
The paint method is invoked once when the applet starts, but it is also called when a repaint() is issued, notice that we issue a repaint() from the action method. The parameter for this method is a Graphics object. Graphics class provides the description of the methods invoked in paint.
The action method is the most interesting one used here. It handles events initiated by the user. In our case, it is invoked when either of our buttons are clicked, it could also get invoked when, for example, the user resizes the browser window. Note that we check, if the action taken by the user was the click of either hello_button or the bye_button. If the event is not one of those two, we pass it along to the action method in the super class (Applet's).