1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Java Tutorials

Parameters to follow Creating and Destroying Objects?

Item 1: Consider providing static factory methods instead of
constructors
public static Boolean valueOf(boolean b) {
return (b ? Boolean.TRUE : Boolean.FALSE);
}
advantage of static factory methods is that, unlike constructors, they are not
required to create a new object each time they're invoked.
This allows immutable classes
(Item 13) to use preconstructed instances or to cache instances as they're constructed and to
dispense these instances repeatedly so as to avoid creating unnecessary duplicate objects.
The Boolean.valueOf(boolean) method illustrates this technique: It never creates an object.
This technique can greatly improve performance if equivalent objects are requested
frequently, especially if these objects are expensive to create.
it allows an immutable class to ensure that no two equal instances exist:
a.equals(b) if and only if a==b. If a class makes this guarantee, then its clients can use
the == operator instead of the equals(Object) method, which may result in a substantial
performance improvement
implements this
optimization, and the String.intern method implements it in a limited form.

advantage of static factory methods is that, unlike constructors, they can return
an object of any subtype of their return type. This gives you great flexibility in choosing
the class of the returned object.
One application of this flexibility is that an API can return objects without making their
classes public. Hiding implementation classes in this fashion can lead to a very compact API.

Item 2: Enforce the singleton property with a private constructor

Item 4: Avoid creating duplicate objects
It is often appropriate to reuse a single object instead of creating a new functionally equivalent
object each time it is needed. Reuse can be both faster and more stylish. An object can always
be reused if it is immutable
As an extreme example of what not to do, consider this statement:
String s = new String("silly"); // DON'T DO THIS!
The statement creates a new String instance each time it is executed, and none of those
object creations is necessary. The argument to the String constructor ("silly") is itself a
String instance, functionally identical to all of the objects created by the constructor. If this
usage occurs in a loop or in a frequently invoked method, millions of String instances can be
created needlessly.
The improved version is simply the following:
String s = "No longer silly";
Item 5: Eliminate obsolete object references
So where is the memory leak? If a stack grows and then shrinks, the objects that were popped
off the stack will not be garbage collected, even if the program using the stack has no more
references to them. This is because the stack maintains obsolete references to these objects.
An obsolete reference is simply a reference that will never be dereferenced again. In this case,
any references outside of the ?active portion? of the element array are obsolete. The active
portion consists of the elements whose index is less than size.

public Object pop() {
if (size == 0)
throw new EmptyStackException();
return elements[--size];
}
The fix for this sort of problem is simple: Merely null out references once they become
obsolete. In the case of our Stack class, the reference to an item becomes obsolete as soon as
it's popped off the stack. The corrected version of the pop method looks like this:
public Object pop() {
if (size==0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference
return result;
}
Item 6: Avoid finalizers
There is no guarantee that finalizers will be executed promptly. It can take
arbitrarily long between the time that an object becomes unreachable and the time that its
finalizer is executed. This means that nothing time-critical should ever be done by a
finalizer. For example, it is a grave error to depend on a finalizer to close open files because
open file descriptors are a limited resource. If many files are left open because the JVM is
tardy in executing finalizers, a program may fail because it can no longer open files.





Reviews and Comments


PMP, CAPM, PMI is a registered certification mark of the Project Management Institute, Inc

Copyright © www.techfaq360.com 2016


About US | Contact US | Privacy Policy | Terms and Conditions  | Website disclaimer  | Cancellation and Refund Policy  | Shipping & Delivery Policy