Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml

AspAutocadCDot netExcelFox proHtmlJava
LinuxMathcadPhotoshopPhpSqlVisual studioWindowsXml

Using imports to change behavior

java

+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Trimite pe Messenger
return
Using imports to change behavior
Upcasting
A method lookup tool
Creating windows and applets
Business Process in Seam
Performance: Locating the bottleneck
Sorting
Utilities: Making a Collection or Map unmodifiable
Controlling layout: FlowLayout, GridLayout


Using imports to change behavior

A feature that is missing from Java is C’s conditional compilation, which allows you to change a switch and get different behavior without changing any other code. The reason such a feature was left out of Java is probably because it is most often used in C to solve cross-platform issues: different portions of the code are compiled depending on the platform that the code is being compiled for. Since Java is intended to be automatically cross-platform, such a feature should not be necessary.




However, there are other valuable uses for conditional compilation. A very common use is for debugging code. The debugging features are enabled during development, and disabled for a shipping product. Allen Holub (www.holub.com) came up with the idea of using packages to mimic conditional compilation. He used this to create a Java version of C’s very useful assertion mechanism, whereby you can say “this should be true” or “this should be false” and if the statement doesn’t agree with your assertion you’ll find out about it. Such a tool is quite helpful during debugging.

Here is the class that you’ll use for debugging:

//: Assert.java

// Assertion tool for debugging

package com.bruceeckel.tools.debug;

public class Assert

public final static void is_true(boolean exp)

public final static void is_false(boolean exp)

public final static void

is_true(boolean exp, String msg)

public final static void

is_false(boolean exp, String msg)

This class simply encapsulates boolean tests, which print error messages if they fail. In Chapter 9, you’ll learn about a more sophisticated tool for dealing with errors called exception handling, but the perr( ) method will work fine in the meantime.

When you want to use this class, you add a line in your program:

import com.bruceeckel.tools.debug.*;

To remove the assertions so you can ship the code, a second Assert class is created, but in a different package:

//: Assert.java

// Turning off the assertion output

// so you can ship the program.

package com.bruceeckel.tools;

public class Assert



public final static void is_false(boolean exp)

public final static void

is_true(boolean exp, String msg)

public final static void

is_false(boolean exp, String msg)

Now if you change the previous import statement to:

import com.bruceeckel.tools.*;

The program will no longer print out assertions. Here’s an example:

//: TestAssert.java

// Demonstrating the assertion tool

package c05;

// Comment the following, and uncomment the

// subsequent line to change assertion behavior:

import com.bruceeckel.tools.debug.*;

// import com.bruceeckel.tools.*;

public class TestAssert

By changing the package that’s imported, you change your code from the debug version to the production version. This technique can be used for any kind of conditional code.

Package caveat

It’s worth remembering that anytime you create a package, you implicitly specify a directory structure when you give the package a name. The package must live in the directory indicated by its name, which must be a directory that is searchable starting from the CLASSPATH. Experimenting with the package keyword can be a bit frustrating at first, because unless you adhere to the package-name to directory-path rule, you’ll get a lot of mysterious run-time messages about not being able to find a particular class, even if that class is sitting there in the same directory. If you get a message like this, try commenting out the package statement, and if it runs you’ll know where the problem lies.






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 360
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site