Complete Java 2 Certification Study Guide, Second Editionby Simon Roberts, Michael Ernest, Philip Heller
Sun Microsystems the creator of Java has two Java Certification Exams one for programmers and one for developers. This Study Guide is the ultimate authority for both of the Sun Certification Tests! The lead author of Sybex's Java 2 Certification Study Guide actually developed the exams for Sun. Roberts was the key player in the concept, strategy, and implementation of the test guidelines, and also developed the questions. The Study Guide is organized according to the exam objectives defined by Sun. Every single objective is covered, reinforced with sample questions and annotated answers. The book has a stamp of approval from the Sun Education Team, and includes a CD with an exclusive Java exam test engine.
- Sybex, Incorporated
- Publication date:
- Edition description:
- Student Manual, Study Guide, etc.
- Product dimensions:
- 7.79(w) x 9.26(h) x 2.22(d)
Read an Excerpt
Chapter 6: Objects and ClassesThis chapter discusses the object-oriented features of Java. Good coding in Java requires a sound understanding of the object-oriented (OO) paradigm, and this in turn requires a good grasp of the language features that implement objects and classes. The many benefits of object orientation have been the subject of considerable public debate, but for most programmers these benefits have not been realized. In most cases, the reason the promise has not been fulfilled is simply that programmers have not been writing objects. Instead, many programmers have been writing hybrid applications with a mixture of procedural and object-oriented code. Unfortunately, such an approach has given rise, not to some of the benefits of OO, but instead to all the disadvantages of both styles.
Benefits of Object-Oriented ImplementationBeginning with the 1.2 examination, you are required to understand the benefits of object-oriented design. These benefits accrue from two particular features of the OO paradigm. The first of these, and perhaps the most important, is the notion of an abstract data type; the second and perhaps better-known is the extensibility provided by inheritance.
Abstract Data TypesAn abstract data type is really just a fancy name for a well-encapsulated aggregate of data and behavior. Consider the primitive data types of any programming language you have ever used. You do not know how these data items are stored and, for the most part, you do not care. What matters are the operations that you can perform on these data items and the boundary conditions within which you can expect those operations to work properly. These primitive types are in fact abstract data types, albeit not user-defined.
Your first goal in defining a good class should be to clearly state the operations that can be applied to instances of that class. Next, consider how to represent the state of the instance, keeping in mind that this should be done only with variables of private accessibility. All behavior should be accessed only via methods. By insisting that the variables inside an object are inaccessible outside the object, you ensure that the nature of those vari-ables is irrelevant outside the object. This in turn means that you can freely change the nature of the storage, for maintenance purposes, for performance improvement, or for any other reason.
Sometimes, perhaps as a consequence of the way you have stored the state in a class, boundary conditions must be applied to its methods. A boundary condition is a limit on the range of arguments for which a method can operate properly. As examples, a square-root function cannot operate conventionally on a negative number; an add operation cannot operate if both of its arguments are more than half the maximum representable range for the operation's return type.
When you encounter a boundary condition that results from your choice of storage format, you must make a choice. If you consider that the bound-ary conditions are reasonable, then you should do two things. First, docu-ment the boundary condition. Next, test the boundary conditions at the entry to the method and, if the boundary condition has been exceeded, throw a runtime exception of some kind. Alternatively, you might decide that the boundary condition is not acceptable, in which case you should redesign the storage used in the class.
Now, consider this: If you had allowed access to any of the variables used to represent the object state, then redefining the way the object's state is stored would immediately cause any other code that uses these variables to have to be rewritten. However, by using only private member variables, we have insisted that all interaction with this object is made through methods and never by direct variable access—so we have eliminated this problem. In consequence, we are able to redesign our internal storage freely and, provided the signatures of all the methods remain the same, no other code needs to change.
Sometimes you will realize that the methods you have provided for a class are inadequate. This is not usually a problem, either. You may add new methods to freely provide additional functionality. No client code will break, provided the methods that were already provided remain available, with the same signatures and the same semantics. The only issues that might arise during maintenance are if you realize that a method you have defined has a fundamentally flawed prototype. This should not happen often, since it implies that the operation you defined for the class was conceptually flawed in some way.
Encapsulation and Perceived EfficiencyMany programmers have such deep-seated concerns about performance that they cannot bring themselves to force all access to their objects to be made through methods, and they resist creating classes with entirely private member variables. There are several reasons why this is an unwise approach. First, fully encapsulated classes are more likely to be used correctly, especially if boundary conditions are properly flagged with excep-tions— therefore, code using them is more likely to be correct. Second, bug fixes and maintenance changes are less likely to break the program as a whole, since the effects of the change are confined to the affected class. These reasons fall into the broad heading of "Would your customer prefer a slow program that works and is delivered on time (and that can be made faster later) or a program that is delivered late, works incorrectly, but runs quickly?"
There are more reasons why fully encapsulated classes are the right way to start out a design. An optimizing virtual machine such as Sun's HotSpot can transparently optimize simple variable access methods by "inlining." This approach allows the program all the robustness, reliability, and maintain-ability that results from full encapsulation, while giving the runtime perfor-mance associated with direct variable access. Furthermore, if you decide that a program's slow performance is attributable to the use of private variables and accessor/mutator methods, then changing the variable to be more accessible does not require any changes to the rest of the code, either inside or outside the class. On the other hand, if you have code that fails to run properly as a result of making direct variable access, you will find that reducing the accessibility of the relevant variable will require considerable collateral changes in many other pieces of code (all code that makes such direct access).
ReuseWe have discussed how tight encapsulation can make code that is more reliable and robust. Now we will consider the second most significant advantage of object-oriented programming: code reuse.
Writing good, encapsulated classes usually requires more work in the initial stages than would have been required to produce the same functionality with a traditional programming approach. While this is true, you will normally find that using rigorous OO techniques will actually reduce the overall time required to produce finished code. This happens for two reasons. The first is that the robust classes you produce actually require less time to integrate into the final program and less time to fix bugs. The second is that with careful design you can reuse classes even in some circumstances that are different from the original intent of the class.
This reuse is actually possible in two ways, using either composition (the "has a" relation) or inheritance (the "is a" relation). Composition is probably safer and easier to control, although inheritance—perhaps because it is perceived as "pure OO"—seems to be more interesting and appealing to most programmers.
The Java certification exam does not require you to discuss details of object-oriented design techniques or the relative merits and weaknesses of composition versus inheritance. However, you should appreciate one significant sequence of facts: If a class is well encapsulated, it will be easier to reuse successfully. The more a class is reused, the better tested it will be and the fewer bugs it will have. Better-tested, less-buggy classes are easier to reuse. This sequence leads to a positive spiral of quality since the better the class, the easier and safer it becomes to reuse. All this comes from tight encapsulation.
Now that we've discussed why you would want to write object-oriented code, let's look at how this is achieved....
Meet the Author
Simon Roberts, the lead author of this book, is a Sun Microsystems programmer, an instructor, an authority on the Java language, and the key player in the development of the entire Java Certification program.
Philip Heller is a consultant, author, educator, and novelist. He worked as an engineer for both Sun and NeXT in the early years.
Mike Ernest is Chief Technical Engineer for Synergistic Computer Solutions in Belmont, CA. He is a Sun-certified instructor as well as a Certified Solaris Administrator and Certified Java Programmer. Roberts and Heller are co-authors of the Java 2 Developer's Handbook, from Sybex.
Most Helpful Customer Reviews
See all customer reviews
I have read this book and I think that this is a good start toward the certification, the book covers alot of topics in a simple easy to understand and memories way, this is an in-bridth coverage rather to be in-depth one, yet it is vey good for the exam.
This book isn't what I expected. Its full of errors and inconsistencies. Did anyone proofread? I had trouble with the code in many places. Overall I came away wondering if the authors knew what they were doing.
This is a great book. Everything you need to know is covered and explained. The sample exams are excellent. I scored mid 70's on the sample exams and also on the real exam.
This is an excellent book to prepare yourself for the Programmers Exam. I'm an undergrad with no experience; took a Java class and studied from this book and PASSED the exam. I learned a lot of things (from this book) about the Java Language that my undergraduate Java class didnt teach me.
This book is an excellent material for the preparation of Java Programmer Certificaiton. The recommended reader level for this book is Intermediate/Advanced ; hence the beginners, should study some other entry level book, before they start reading this book. The test at the end of each topic and their answers at the end of the book are comprehensive and are adequete to build a good understanding level for the readers.
I study Java 2 from other books and bought this book so I could check how well I am doing. This book is excellent for that purpose. I am not studying for either of the exams (Programmer's or Developer's) but this book is very valuable. The first 400 pages are about the programmer's exam. Each chapter is about one objective and in the end you can take a full mock test about the whole area. This first part is what I use frequently to test my skills and knowledge. The rest of the book is not so precise, for the Developer's exam is not about multiple choice questions. This part has articles about how a sample problem, similar to those in the exam, is solved apropriately. If you are studying Java 2 and need a way to keep sure that you are learning what the trade and business needs, this book is an excellent companion.