| << Chapter < Page | Chapter >> Page > |
StraightBall ,
CurveBall and
WanderBall are thus concrete variants of
ABall . They represent the
variant behaviors of the system. Other than in their constructors (which will prove to be a significant point when this inheritance-based model is compared to a more advanced composition-based model), these concrete subclasses only code the abstract variant behavior associated with a ball, namely the
updateState method. Inheritance gives any instantiation of these classes both the invariant behaviors from the
ABall superclass plus the variant behaviors from the subclass.
The Ballworld code demonstrates the importance of the concept of separation of variant and invariant behaviors .
Clearly and cleanly separating the variant and invariant behaviors in a program is crucial for achieving flexible, extensible, robust and correct program execution.Where and how to separate the variant and invariant behaviors is arguably the most important design consideration made in writing god software.
Packages are way that Java organizes related classes together. Packages are simply directories that contain the related code files. Each class file in a package directory should have the line
package XXX; at its top, where the
XXX matches with the directory. name. If neither
public nor
private (nor
protected -- i.e. a blank specifier) is used to specify the visibility level of a class or method, then that method can be seen by other members of the package but not by those outside of the package. To use the public classes in a package, the
import myPackage.*; syntax is used. This tells the Java compiler to allow all the public classes in the
myPackage directory. Packages can be nested, though each level must be imported separately.
Static fields and methods, denoted by the
static keyword in their declarations, are fields and methods that can be accessed at a class level, not just an object level. In general these are values or behaviors that one wishes for all instances of a class to have access to. These values and behaviors are necessarily independent of the state of any particular instance. Static fields and methods are often referred to as "
class variables " and "
class methods ".
An examples of a class variables are
Math.PI and
Color.BLUE or
Color.RED . These are universal values associated with math and color respectively and thus do not need an object instance to be viable. By convention, all static field names are in all capitol letters. A static field is referenced simply by writing the class name followied by a period and then by the field name. No instantiations are necessary.
The
Randomizer class contains numerous static methods. This is because each of the methods to produce various random values is independent of each other and that the process in each method does not affect nor is affected by the state of the rest of the class. Essentially, this entails that the class contain no non-static fields. A class as such is referred to as being "
stateless ". Just like a static field, a static method is invoked in the same manner as the static fields:
ClassName.staticMethodName(...) Classes with static methods are usually utility classes that are used to hold a set of related functional processes, e.g.
Randomizer holds a collection of random value generators. Likewise,
Math holds a combination of static values, such as
PI and static methods such as
sin () and
cos ().
There is one very special static method with the following
exact signature:
public static void main(String[] args) This method, found in
BallControl , is the method that Java uses to start programs up. Since OO programs are systems of interacting objects, this static "main" method is used to create the first object(s) and get the program up and running. So when Java starts a program, it looks for this and only this method.
When concrete methods or the constructor of a superclass are overriden, sometimes it is necessary or desirable to call the original superclass behavior from the subclass. A common reason for this is that the subclass's behavior is simple an addition to the superclass behavior. One does not want to replicate the superclass code, so a call to the superclass's original methods is required at some point in the subclasses overriding method. To accomplish this, Java uses the
super keyword.
super refers to the superclass instance, just as
this refers to the class instance itself (the subclass here). Note that technically,
super and
this are the same object -- think of it as the difference between the
super and
this is a Freudian slip?)
Suppose the superclass has a method called
myMethod() which the subclass overides. For the subclass to call the superclass's
myMethod , it simply needs to say
super.myMethod() . Contrast this to the subclass calling its own
myMethod :
this.myMethod() (note: Java syntax rules allow for the
this to be omitted).
To make a call to the superclass's constructor the subclass simply says
super(...) , supplying wahtever parameters the superclass constructor requires. This is a very common scenario as the the subclass almost always needs to superclass to initialize itself before it can perform any additional initializations. Thus the
super(...) call must be the first line in the subclass's constructor. If the no-parameter constructor of the superclass is required, the call to
super can be omitted as it will be automatically performed by the Java run-time engine. This of course presumes that the superclass's no-parameter constructor exists, which it does
not if a parameterized constructor has been declared without explicitly declaring the no-parameter constructor.
Notification Switch
Would you like to follow the 'Principles of object-oriented programming' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|