Declare Classes (Exam Objective 1.1)
1.1 Develop code that declares classes (including abstract and all forms of nested classes), interfaces, and enums, and includes the appropriate use of package and import statements (including static imports).
When you write code in Java, you're writing classes or interfaces. Within those classes, as you know, are variables and methods (plus a few other things). How you declare your classes, methods, and variables dramatically affects your code's behavior. For example, a public method can be accessed from code running anywhere in your application. Mark that method private, though, and it vanishes from everyone's radar (except the class in which it was declared). For this objective, we'll study the ways in which you can declare and modify (or not) a class. You'll find that we cover modifiers in an extreme level of detail, and though we know you're already familiar with them, we're starting from the very beginning. Most Java programmers think they know how all the modifiers work, but on closer study often find out that they don't (at least not to the degree needed for the exam). Subtle distinctions are everywhere, so you need to be absolutely certain you're completely solid on everything in this section's objectives before taking the exam.
Source File Declaration Rules
Before we dig into class declarations, let's do a quick review of the rules associated with declaring classes, import statements, and package statements in a source file:
■ There can be only one public class per source code file.
■ Comments can appear at the beginning or end of any line in the source code file; they are independent of any of the positioning rules discussed here.
■ If there is a public class in a file, the name of the file must match the name of the public class. For example, a class declared as public class Dog { } must be in a source code file named Dog.java.
■ If the class is part of a package, the package statement must be the first line in the source code file, before any import statements that may be present.
■ If there are import statements, they must go between the package statement (if there is one) and the class declaration. If there isn't a package statement, then the import statement(s) must be the first line(s) in the source code file. If there are no package or import statements, the class declaration must be the first line in the source code file.
■ import and package statements apply to all classes within a source code file. In other words, there's no way to declare multiple classes in a file and have them in different packages, or use different imports.
■ A file can have more than one nonpublic class.
■ Files with no public classes can have a name that does not match any of the classes in the file.
In Chapter 10 we'll go into a lot more detail about the rules involved with declaring and using imports, packages, and a feature new to Java 5, static imports.
Class Declarations and Modifiers
Although nested (often called inner) classes are on the exam, we'll save nested class declarations for Chapter 8. You're going to love that chapter. No, really. Seriously.
The following code is a bare-bones class declaration:
class MyClass { }
This code compiles just fine, but you can also add modifiers before the class declaration. Modifiers fall into two categories:
■ Access modifiers: public, protected, private.
■ Non-access modifiers (including strictfp, final, and abstract).
We'll look at access modifiers first, so you'll learn how to restrict or allow access to a class you create. Access control in Java is a little tricky because there are four access controls (levels of access) but only three access modifiers. The fourth access control level (called default or package access) is what you get when you don't use any of the three access modifiers. In other words, every class, method, and instance variable you declare has an access control, whether you explicitly type one or not. Although all four access controls (which means all three modifiers) work for most method and variable declarations, a class can be declared with only public or default access; the other two access control levels don't make sense for a class, as you'll see.
Java is a package-centric language; the developers assumed that for good organization and name scoping, you would put all your classes into packages. They were right, and you should. Imagine this nightmare: Three different programmers, in the same company but working on different parts of a project, write a class named Utilities. If those three Utilities classes have not been declared in any explicit package, and are in the classpath, you won't have any way to tell the compiler or JVM which of the three you're trying to reference. Sun recommends that developers use reverse domain names, appended with division and/or project names. For example, if your domain name is geeksanonymous.com, and you're working on the client code for the TwelvePointOSteps program, you would name your package something like com.geeksanonymous.steps.client. That would essentially change the name of your class to com.geeksanonymous.steps.client.Utilities. You might still have name collisions within your company, if you don't come up with your own naming schemes, but you're guaranteed not to collide with classes developed outside your company (assuming they follow Sun's naming convention, and if they don't, well, Really Bad Things could happen).
Class Access
What does it mean to access a class? When we say code from one class (class A) has access to another class (class B), it means class A can do one of three things:
■ Create an instance of class B.
■ Extend class B (in other words, become a subclass of class B).
■ Access certain methods and variables within class B, depending on the access control of those methods and variables.
In effect, access means visibility. If class A can't see class B, the access level of the methods and variables within class B won't matter; class A won't have any way to access those methods and variables.
Default Access
A class with default access has no modifier preceding it in the declaration! It's the access control you get when you don't type a modifier in the class declaration. Think of default access as package-level access, because a class with default access can be seen only by classes within the same package. For example, if class A and class B are in different packages, and class A has default access, class B won't be able to create an instance of class A, or even declare a variable or return type of class A. In fact, class B has to pretend that class A doesn't even exist, or the compiler will complain. Look at the following source file:
package cert;
class Beverage { }
Now look at the second source file:
package exam.stuff;
import cert.Beverage;
class Tea extends Beverage { }
As you can see, the superclass (Beverage) is in a different package from the subclass (Tea). The import statement at the top of the Tea file is trying (fingers crossed) to import the Beverage class. The Beverage file compiles fine, but when we try to compile the Tea file we get something like:
Can't access class cert.Beverage. Class or interface must be public, in same package, or an accessible member class.
import cert.Beverage;
Tea won't compile because its superclass, Beverage, has default access and is in a different package. You can do one of two things to make this work. You could put both classes in the same package, or you could declare Beverage as public, as the next section describes.
When you see a question with complex logic, be sure to look at the access modifiers first. That way, if you spot an access violation (for example, a class in package A trying to access a default class in package B), you'll know the code won't compile so you don't have to bother working through the logic. It's not as if you don't have anything better to do with your time while taking the exam. Just choose the "Compilation fails" answer and zoom on to the next question.
Public Access
A class declaration with the public keyword gives all classes from all packages access to the public class. In other words, all classes in the Java Universe (JU) have access to a public class. Don't forget, though, that if a public class you're trying to use is in a different package from the class you're writing, you'll still need to import the public class.
In the example from the preceding section, we may not want to place the subclass in the same package as the superclass. To make the code work, we need to add the keyword public in front of the superclass (Beverage) declaration, as follows:
package cert;
public class Beverage { }
This changes the Beverage class so it will be visible to all classes in all packages. The class can now be instantiated from all other classes, and any class is now free to subclass (extend from) it—unless, that is, the class is also marked with the nonaccess modifier final. Read on.
Related Topics : SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-1
SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-2
SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-3
SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-4
SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-5
SCJP Sun Certified Programmer for Java 6 Study Guide Exam(310-065) Class-6
No comments:
Post a Comment