Higher and higher
Menu

Web Push?
Collections
IDL Design
Java In Practice
Singleton
Contact Us
-- Home --


Announcements

A new look for a New Year! Help us to reach new summits.


Selected Partners

Java In Practice

Introduction:

Buy @ amazonHere follows a summary of the book "Java In Practice" by Nigel Warren, Phil Bishop. This is definitely a hands-on book where intermediate/expert java developers will find a source of new ideas and a repository of experience in a clear and concise manner. Most of the tips and hints are very relevant. Recommended!

And... you can even buy the book here

Encapsulation

  • Aim to make all of your instance variables private and provide accessor methods where necessary.
  • Make accessor methods for instance variables final.
  • Only use protected instance variables or protected constructors in well-defined packages.
  • Use packages constantly to manage complexity.
  • If a class is only used within a package, make it package local (default visibility) to reduce system-level coupling.
  • Prefer the use of packages over static inner classes.
  • An inner class only makes sense, and should only be used, if it is going to associate and be visible only to the class that contains it.

Inheritance

  • Constructors are not inherited.
  • Keep inheritance hierarchies small.
  • Prefer delegation or using utility classes over inheritance for re-use.
  • Inheritance is a class-based, "is a type of" relationship.
  • All classes implicitly inherits from the class Object.
  • Avoid unnecessary casting.
  • Interfaces cannot define constructors.
  • Programme to an interface, not an implementation.
  • If a class is designed to be inherited, but it does not make sense to have an instance of the class, it should be defined as abstract.
  • Abstract classes that contain only method signatures and static final fields should be declared as interfaces.

Polymorphism

  • The JVM will always search up the inheritance hierarchy from the real class of the target object, in order to find the first match for the signature of the target method, no matter what the apparent type of the object is at the time of the call.
  • Migrate common instance variables and concrete accessor methods to an abstract class that can lie between the interface and concrete classes in a hierarchy.

Type Safety And Constants

  • Get your compiler to check that constants passed as parameters are valid.
  • Declare method parameters as final when you want to guard against meaningless object reference assignment.
  • Use a read-only interface to make mutable object act as immutable.
  • Understand the difference between shallow and deep copying.

Exceptions

  • Catch as many exceptions as possible explicitly - avoid catch(Exception e) as the only exception handler.
  • Identify exception classes during the design phase.
  • Avoid using try {...} catch {...} on a per method basis for all methods within a block.
  • Separate fatal and non-fatal exception class hierarchies.
  • Reduce the overall number of exception classes by categorizing them and using a constant (typesafe) to represent the condition.
  • Never let exceptions propagate out of a finally block.
  • Never declare throws Exception. Always use a subclass of Exception.
  • Understand the implications of throwing exceptions in constructors.
  • Use exceptions to indicate exceptional and error conditions, not to return values from methods.

Loading Classes And Creating Objects

  • Use constructor chaining to make constructor behaviour and default values appear in only one place in the chain.
  • Use private helper methods to avoid super() and this() conflicts in constructor chaining.
  • Never call an abstract method from a constructor in an abstract class.
  • Always call super.finalize() at the end of a finalize() method.
  • Never call finalize() explicitly.

Balancing Performance and Resource Usage

  • Consider lazy instantiation as a policy to reduce resource requirements.
  • Avoid lazy instantiation for concrete Singleton classes.
  • Make methods using lazy instantiation "thread-safe", if they can be called either directly or indirectly by client classes.
  • Use the double-check idiom to protect methods using lazy instantiation.

© 2003 Xhenseval.com. All rights reserved. Page design by B a s i c T e m p l a t e s . c o m.
Site Meter