Lazy initialization

http://www.javapractices.com/topic/TopicAction.do?Id=34

Lazy initialization of a field may be useful when both of these conditions are true :

* the field is particularly expensive to create
* the field has an optional character, in the sense that it may or may not be of interest to the caller

In this case, the construction of such a field may be deferred till the moment it is actually required. This increases performance by avoiding unnecessary creation of expensive objects.

Immutable objects

http://www.javapractices.com/topic/TopicAction.do?Id=29

Immutable objects are simply objects whose state (the object's data) cannot change after construction. Examples of immutable objects from the JDK include String and Integer.

Immutable objects greatly simplify your program, since they :

* are simple to construct, test, and use
* are automatically thread-safe and have no synchronization issues
* do not need a copy constructor
* do not need an implementation of clone
* allow hashCode to use lazy initialization, and to cache its return value
* do not need to be copied defensively when used as a field
* make good Map keys and Set elements (these objects must not change state while in the collection)
* have their class invariant established once upon construction, and it never needs to be checked again
* always have "failure atomicity" (a term used by Joshua Bloch) : if an immutable object throws an exception, it's never left in an undesirable or indeterminate state

Immutable objects have a very compelling list of positive qualities. Without question, they are among the simplest and most robust kinds of classes you can possibly build. When you create immutable classes, entire categories of problems simply disappear.

Make a class immutable by following these guidelines :

* ensure the class cannot be overridden - make the class final, or use static factories and keep constructors private
* make fields private and final
* force callers to construct an object completely in a single step, instead of using a no-argument constructor combined with subsequent calls to setXXX methods (that is, avoid the Java Beans convention)
* do not provide any methods which can change the state of the object in any way - not just setXXX methods, but any method which can change state
* if the class has any mutable object fields, then they must be defensively copied when passed between the class and its caller

Hash Code

http://www.devx.com/tips/Tip/5839



What is an Object's Hash Code?
Objects in Java have hash codes associated with them. An object's hash code is a signed number that identifies the object (for example, an instance of the parent class). An object's hash code may be obtained by using the object's hashCode() method as follows:


int hashCode = SomeObject.hashCode();

The method hashCode() is defined in the Object class and is inherited by all Java objects. The following code snippet shows how the hash codes of two objects relate to the corresponding equals() method:


1. // Compare objects and then compare their hash codes
2. if (object1.equals(object2)
3. System.out.println("hash code 1 = " + object1.hashCode() +
4. ", hashcode 2 = " + object2.hashCode());
5.
6. // Compare hash codes and then compare objects
7. if (object1.hashCode() == object2.hashCode())
8. {
9. if (object1.equals(object2))
10. System.out.println"object1 equals object2");
11. else
12. System.out.println"object1 does not equal object2");
13. }

By definition if two objects equal (o1.equals(o2)) then calling their hashCode() method must produce the same integer value.
This is essencial to the correct working of a hash table. Don't forget if you override equals, always override hashCode() as well.

Python

Python is an interpreted programming language.-- a language which is never actually compiled in full,it compiles the bits of the program you are using as you are using them.

indention is very important

example: http://www.sthurlow.com/python/lesson04/

Singleton

public class Aclass{

private static A uniqueInstance;

private Aclass();

public Static Aclass getInstance(){

if(uniqueInstance == null)

uniqueInstance = new Aclass();

return uniqueInstance;

}

}

Strategy Pattern

defines a family of algorithms, encapsulates each one, and makes them interchangeable.Strategy lets the algorithm vary independently from clients that use it.

Class A{
SortInterface i;
}

Interface SortInterface{
sort();
}

Class ConcreteAlgorithm1 implements SortInterface{
sort(){
...
}

}

Class ConcreteAlgorithm2 implements SortInterface{
sort(){
...
}

}

a family of sort algorithms

Design principles

1. Identify the aspects of your application that vary and separate them from what stays the same. Take the parts that vary and encapsulate them,

take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don't.

All patterns provide a way to let some part of a system vary independently of all other parts.

2. Program to an interface, not an implementation.

The point is to exploit polymorphism by programming to a supertype so that the actual runtime object isn't locked into the code.

The declared type of the variables should be a supetype, usually an abstract class or interface, so that the objects assigned to those variables can be of any concrete implementation of the supertype, which means the class declaring them doesn't have to know about the actual object type. (page 12)

3. Favor composition over inheritance.
class A{
BehaviorClass1 behavior1;
BehaviorClass1 behavior2;
}

When you put two classes together like this you're using composition. Instead of inheriting their behavior,the class A get their behavior by being composed with the right behavior object.

Not only does it let you encapsulate a family of algorithms into their own set of classes, but it also lets you change behavior at runtime as long as the object you'are composing with implements the correct behavior interface.