EJ-36 Consistently Use the Override Annotation

This is the case I meet frequently, thanks to Eclipse, it puts automatically when a class implements an interface or extends a super class.

Ref: Effective Java by Joshua Bloch

Can you spot the bug?:

	// Can you spot the bug?
	public class Bigram {
	private final char first;
	private final char second;
	public Bigram(char first, char second) {
	this.first = first;
	this.second = second;
	}
	public boolean equals(Bigram b) {
	return b.first == first && b.second == second;
	}
	public int hashCode() {
	return 31 * first + second;
	}
	public static void main(String[] args) {
	Set<Bigram> s = new HashSet<Bigram>();
	for (int i = 0; i < 10; i++)
	for (char ch = 'a'; ch <= 'z'; ch++)
	s.add(new Bigram(ch, ch));
	System.out.println(s.size());
	}
	}

view raw UseOverrideAnnotation.java hosted with ❤ by GitHub

The program tries to utilize equals method of Object by intention of overriding equals method, but it can not, since to override Object.equals, you must define an equals method whose parameter is of type Object. 

Luckily, the compiler can help you find this error, but only if you help the compiler by telling it that you intend to override Object.equals. To do this, annotate Bigram.equals with @Override as shown below

@Override public boolean equals(Bigram b) {

      return b.first == first && b.second == second;

}

Therefore, you should use the Override annotation on every method decleration that you believe to override a superclass decleration.

EJ-35 Prefer Annotations to naming patterns

Ref: Effective Java by Joshua Bloch

Prior to release 1.5, it was a common to use naming pattern to indicate that some program elements demanded special treatment by a tool or a framework. For example, the JUnit testing framework originally required its users to designate test methods by beginning theri names with the characters test. This technique works but

• it is open to typograhapicals error.
• There is no way to associate parameter values with program elements (such as marking a test method with exception expectation)

Annotations solve all of these problems. Here is a sample annotation type, named Test:

	// Marker annotation type declaration
	import java.lang.annotation.*;
	/**
	* Indicates that the annotated method is a test method.
	* Use only on parameterless static methods.
	*/
	@Retention(RetentionPolicy.RUNTIME)
	@Target(ElementType.METHOD)
	public @interface Test {
	}

view raw TestAnnotation.java hosted with ❤ by GitHub

Annotations have no direct effect on the semantics of class, they serve only to provide information for use by interested programes, enabling it for special treatment by tools such as this simple test runner by checking isAnnotationPresent on method, see line 10.

	// Program to process marker annotations
	import java.lang.reflect.*;
	public class RunTests {
	public static void main(String[] args) throws Exception {
	int tests = 0;
	int passed = 0;
	Class testClass = Class.forName(args[0]);
	for (Method m : testClass.getDeclaredMethods()) {
	if (m.isAnnotationPresent(Test.class)) {
	tests++;
	try {
	m.invoke(null);
	passed++;
	} catch (InvocationTargetException wrappedExc) {
	Throwable exc = wrappedExc.getCause();
	System.out.println(m + " failed: " + exc);
	} catch (Exception exc) {
	System.out.println("INVALID @Test: " + m);
	}
	}
	}
	System.out.printf("Passed: %d, Failed: %d%n",
	passed, tests - passed);
	}
	}

view raw RunTests.java hosted with ❤ by GitHub

 

EJ-31 Use Instance Fields instead of Ordinals

Ref: Effective Java by Joshua Bloch

All enums have an ordinal merhod which returns the numerical position of each enum constant in its type. You may be tempted to derive an associated int value from the ordinal

	// Abuse of ordinal to derive an associated value - DON'T DO THIS
	public enum Ensemble {
	SOLO, DUET, TRIO, QUARTET, QUINTET,
	SEXTET, SEPTET, OCTET, NONET, DECTET;
	public int numberOfMusicians() { return ordinal() + 1; }
	}

view raw AbuseOrdinal.java hosted with ❤ by GitHub

While this enum works, it is a maintenance nightmare to depend ordinal value which value changes in case of constants are reordered. The enum specification has this to say about ordinal: "Most programmers will have no use for this method, it is designed for use by general-purpose enum based data structures as EnumSet and EnumMap".

Luckily, there is a simple solution to these problem. Never derive a value associated with an enum form its ordinal; store it in an instance field instead:

	public enum Ensemble {
	SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),
	SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8),
	NONET(9), DECTET(10), TRIPLE_QUARTET(12);
	private final int numberOfMusicians;
	Ensemble(int size) { this.numberOfMusicians = size; }
	public int numberOfMusicians() { return numberOfMusicians; }
	}

view raw EnumInstanceField.java hosted with ❤ by GitHub

 

EJ-30 Use Enum instead of Int Constants

Ref: Effective Java by Joshua Bloch

	// The int enum pattern - severely deficient!
	public static final int APPLE_FUJI = 0;
	public static final int APPLE_PIPPIN = 1;
	public static final int APPLE_GRANNY_SMITH = 2;
	public static final int ORANGE_NAVEL = 0;
	public static final int ORANGE_TEMPLE = 1;
	public static final int ORANGE_BLOOD = 2;

view raw IntEnumPattern hosted with ❤ by GitHub

Here is how it looks in its simplest enum form.

	public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
	public enum Orange { NAVEL, TEMPLE, BLOOD }

view raw SimpleEnum.java hosted with ❤ by GitHub

The basic idea behind Java's enum types is simple: they are classes that export one instance for each enumeration constant via a public static final field. Enum types are effectively final, by virtue of having no accessible constructors. They are generalization of singleton.

Let's go on with richer enum forms with methods and fields. For a nice example of a rich enum type, consider the eight planets of our solar system. Each planet has a mass and radius, and from these two attributes youcan compute its surface gravitiy.

	// Enum type with data and behavior
	public enum Planet {
	MERCURY(3.302e+23, 2.439e6),
	VENUS (4.869e+24, 6.052e6),
	EARTH (5.975e+24, 6.378e6),
	MARS (6.419e+23, 3.393e6),
	JUPITER(1.899e+27, 7.149e7),
	SATURN (5.685e+26, 6.027e7),
	URANUS (8.683e+25, 2.556e7),
	NEPTUNE(1.024e+26, 2.477e7);
	private final double mass; // In kilograms
	private final double radius; // In meters
	private final double surfaceGravity; // In m / s^2
	// Universal gravitational constant in m^3 / kg s^2
	private static final double G = 6.67300E-11;
	// Constructor
	Planet(double mass, double radius) {
	this.mass = mass;
	this.radius = radius;
	surfaceGravity = G * mass / (radius * radius);
	}
	public double mass() { return mass; }
	public double radius() { return radius; }
	public double surfaceGravity() { return surfaceGravity; }
	public double surfaceWeight(double mass) {
	return mass * surfaceGravity; // F = ma
	}
	}

view raw PlanetEnum.java hosted with ❤ by GitHub

Enums are by their nature immutable, so all fields should be final.

While the Planet enum is simple, it is surprisingly powerful. Note that Planet, like all enums, has a static values method that returns an array o fits values in the order they were declared. Note also that the toString method returns the declared name of each enum value.

	public class WeightTable {
	public static void main(String[] args) {
	double earthWeight = Double.parseDouble(args[0]);
	double mass = earthWeight / Planet.EARTH.surfaceGravity();
	for (Planet p : Planet.values())
	System.out.printf("Weight on %s is %f%n",
	p, p.surfaceWeight(mass));
	}
	}

view raw WeightTable.java hosted with ❤ by GitHub

The technique demonstrated in the Planet example are sufficient for most enum types, but sometimes you need to associate fundamentally different behavior with each constant. One way to achieve this is to switch on the value of the enum.

	// Enum type that switches on its own value - questionable
	public enum Operation {
	PLUS, MINUS, TIMES, DIVIDE;
	// Do the arithmetic op represented by this constant
	double apply(double x, double y) {
	switch(this) {
	case PLUS: return x + y;
	case MINUS: return x - y;
	case TIMES: return x * y;
	case DIVIDE: return x / y;
	}
	throw new AssertionError("Unknown op: " + this);
	}
	}

view raw EnumOperation.java hosted with ❤ by GitHub

This code works but it isn't very pretty. Consider below powerful side of Enum, implementing abstract method in each Enum instance

	// Enum type with constant-specific method implementations
	public enum Operation {
	PLUS { double apply(double x, double y){return x + y;} },
	MINUS { double apply(double x, double y){return x - y;} },
	TIMES { double apply(double x, double y){return x * y;} },
	DIVIDE { double apply(double x, double y){return x / y;} };
	abstract double apply(double x, double y);
	}

view raw AbstractEnum.java hosted with ❤ by GitHub

If you add a new constant to the second version of Operation, it is unlikely that you'll forget t oprovide an apply method, as the method immediately follows each constant decleration.

So when should you use enums? Anytime you need a fixed set of constants. Of course, this includes "natural enumerated types" such as planets, the days of the week, and the chess pieces, but it also includes other sets for which you know all the possible values at compile time such as choices on a menu, operation codes etc.

EJ-23 Java Generics Terminology

Term	Example
Parameterized Type	List
Actual  Type Parameter	String
Generic Type	List
Format Type Parameter	E
Unbounded Wildcard Type	List
Raw Type	List
Bounded Type Parameter
Recursive Type Bound	>
Bounded Wildcard Type	List
Generic Method	static List asList
Type Token	String.class

EJ-21 Use Function Objects to Represent Strategies

Ref: Effective Java by Joshua Bloch

Strategy classes are often declered using anonymous classes and pessed to target operation. The following statement sorts an array of strings according to length:

	Arrays.sort(stringArray, new Comparator<String>() {
	public int compare(String s1, String s2) {
	return s1.length() - s2.length();
	}
	});

view raw InnerClassStrategy.java hosted with ❤ by GitHub

But note that using an anonymous class in this way will create a new instance each time the call is executed. When it is expected for repeated use, it is generally implemented as a private static member class and exported in a public static final field whose type is the strategy interface

	// Exporting a concrete strategy
	class Host {
	private static class StrLenCmp
	implements Comparator<String>, Serializable {
	public int compare(String s1, String s2) {
	return s1.length() - s2.length();
	}
	}
	// Returned comparator is serializable
	public static final Comparator<String>
	STRING_LENGTH_COMPARATOR = new StrLenCmp();
	... // Bulk of class omitted
	}

view raw ConcreteStrategy.java hosted with ❤ by GitHub

EJ-19 Use Interfaces only to define types

Ref: Effective Java by Joshua Bloch

In this item, Mr Bloch mention about same symptom I have faced previously and shared in this post.

The constant interface pattern is a poor use of interfaces:

	// Constant interface antipattern - do not use!
	public interface PhysicalConstants {
	// Avogadro's number (1/mol)
	static final double AVOGADROS_NUMBER = 6.02214199e23;
	// Boltzmann constant (J/K)
	static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
	// Mass of the electron (kg)
	static final double ELECTRON_MASS = 9.10938188e-31;
	}

view raw ConstantInterfaceAntiPattern.java hosted with ❤ by GitHub

Instead use a utility class

	// Constant utility class
	package com.effectivejava.science;
	public class PhysicalConstants {
	private PhysicalConstants() { } // Prevents instantiation
	public static final double AVOGADROS_NUMBER = 6.02214199e23;
	public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
	public static final double ELECTRON_MASS = 9.10938188e-31;
	}

view raw ConstantUtilityClass.java hosted with ❤ by GitHub

If you make heavy use of the constants exported by a utility class, you can avoid the need for qualifying the constants with the class name by making use of the static import facility

	// Use of static import to avoid qualifying constants
	import static com.effectivejava.science.PhysicalConstants.*;
	public class Test {
	double atoms(double mols) {
	return AVOGADROS_NUMBER * mols;
	}
	}

view raw StaticImport.java hosted with ❤ by GitHub

In summary, interfaces should be used only to define types, they should not be used to export constants.

EJ-15 Minimize Mutability

Ref: Effective Java by Joshua Bloch

An immutable class is simply a class whose instances can not be modified, all of the information contained in each instance is provided when it is created and is fixed for the lifetime of object.
There are many good reasons for this: Immutable classes are easier to design, implement and use than mutable classes. They are less prone to error and are more secure.
To make class immutable:

1. Don't provide any methods that modify the object's state 
2. Ensure that theclass can't be extended.
3. Make all fields final.
4. Make all fields private.

Here is a good sample of immutable class, Notice how the aritmetic operations create and return a new Complex instance rather than modifying this instance.

	public final class Complex {
	private final float re;
	private final float im;
	public Complex(float re, float im) {
	this.re = re;
	this.im = im;
	}
	// Accessors with no corresponding mutators
	public float realPart() { return re; }
	public float imaginaryPart() { return im; }
	public Complex add(Complex c) {
	return new Complex(re + c.re, im + c.im);
	}
	public Complex subtract(Complex c) {
	return new Complex(re - c.re, im - c.im);
	}
	public Complex multiply(Complex c) {
	return new Complex(re*c.re - im*c.im,
	re*c.im + im*c.re);
	}
	public Complex divide(Complex c) {
	float tmp = c.re*c.re + c.im*c.im;
	return new Complex((re*c.re + im*c.im)/tmp,
	(im*c.re - re*c.im)/tmp);
	}
	public boolean equals(Object o) {
	if (o == this)
	return true;
	if (!(o instanceof Complex))
	return false;
	Complex c = (Complex)o;
	return (Float.floatToIntBits(re) == // See page 33 to
	Float.floatToIntBits(c.re)) && // find out why
	(Float.floatToIntBits(im) == // floatToIntBits
	Float.floatToIntBits(im)); // is used.
	}
	public int hashCode() {
	int result = 17 + Float.floatToIntBits(re);
	result = 37*result + Float.floatToIntBits(im);
	return result;
	}
	public String toString() {
	return "(" + re + " + " + im + "i)";
	}
	// Public constants - Page 66
	public static final Complex ZERO = new Complex(0, 0);
	public static final Complex ONE = new Complex(1, 0);
	public static final Complex I = new Complex(0, 1);
	public static void main(String args[]) {
	Complex x = new Complex(2, 3);
	Complex y = new Complex(2,-3);
	System.out.println(x + " + " + y + " = " + x.add(y));
	System.out.println(x + " - " + y + " = " + x.subtract(y));
	System.out.println(x + " * " + y + " = " + x.multiply(y));
	System.out.println(x + " / " + y + " = " + x.divide(y));
	System.out.println(x.divide(y).multiply(y));
	}
	}

view raw Immutable.java hosted with ❤ by GitHub

• Immutable objects are simple, an immutable object can be in exactly one state, the state in which it was created.
• Immutable ojects are inherently thread-safe; they require no synchronization
• Immutable ojects can be shared freely. One easy way to do this is to rpvoide public static final constants for frequently used values, for example

    public static final Complex ZERO = new Complex(0, 0);   

    public static final Complex ONE  = new Complex(1, 0);   

    public static final Complex I  =   new Complex(0, 1); 

 

 To summarize, resist the urge to write a setter method for every getter method. Classes should be immutable unless there's a very good reason to make them mutable.

A Brake for Music

Gullerin Icinden by MFO,

First recorded by guitar rhythm then another record over it with solo, Hope to enjoy

A Developer's Life In GIF

When I’m deploying code to production :), if I don't have confidence with unit test of course.





Here is whole set of list, ATTENTION for convulsions :)

http://www.codingbyte.com/a-developers-life-in-gif/

http://www.codingbyte.com/a-developers-life-in-gif-part-2/

Firefox SesliSozluk add-on DIY

Civilization advances by extending the number of important operations we can perform without thinking. Alfred North Whitehad

In Tip#61 of Pragmatic Programmer , it is said that "Don't use Manual Procedures".

Tonight, I said it is enough each time to look a meaning of a word while reading on internet

1. open a new tab in browser, 
2. go to www.seslisozluk.com and 
3. enter the word to get meaning. 

As i searched, there were no appropriated firefox add-on matching to my needs, so why i don't prepare one. It is so simple and does not offer no more than what i have needed :). Just select the word and right click and click on "Sesli Sozluk" from the opened menu. Sesli Sozluk will be pop-up with meaning of the selected word.

Here you can get it and don't forget to rate it by 5 stars  :)

I found chrome alternative here prepared by another gentlemen, and don't forget to rate it by 5 stars too :)

EJ-5 Avoid Creating Unnecessary Object

Ref: Effective Java by Joshua Bloch

In Item-5 of Effctive Java, Mr Bloch expresses that avoid creating unnecessary object. In essence, this requires knowing your tool, Java.

String s = new String("test"); //DON'T DO THIS

The statement creates a new String instance each time it is executed. The improved version is simply the following:

String s = "test";

This version uses a single String instance, rathe rthan creating new one each time it is executed. This idiom is called String Interning.
Here is a really interesting sample code demonstrating String interning.

	public class StringIntern {
	public static void main(String[] args) {
	String s1 = "test";
	String s2 = "test";
	checkEquality(s1, s2);
	String s3 = new String("test");
	String s4 = new String("test");
	checkEquality(s3, s4);
	}
	public static void checkEquality(String s1, String s2) {
	System.out.println(System.identityHashCode(s1));
	System.out.println(System.identityHashCode(s2));
	System.out.println(s1.equals(s2));
	System.out.println(s1 == s2);
	}
	}

view raw StringIntern.java hosted with ❤ by GitHub

First checkEquality results that both two strings are exatly same instance with same identity code and both == and equals() give true.
Second checkEquality results that two strings are different instances created with different identity codes and == results false but equals() results true.

396857438
396857438
true
true
2046236531
1294253459
true
false

Mr Bloch advices to avoid unnecessary objects by using static factory methods in preference to constructors on immutable classes. If a class preferable immutable, why you should create new instance each time instead of creating one and using it.

Boolean.valueOf(String) is almost always preferable to the constructor Boolean(String)

Boolean.TRUE is implemented inside Boolean class as a static final Boolean element:

public static final Boolean TRUE = new Boolean(true);

EJ-4 Enforce Noninstantiability with a Private Constructor

Ref: Effective Java by Joshua Bloch

Occasionally you'll want to write a class that is just a grouping of static methods and static fields like java.util.Collections. Such utility classes were not designed to be instantiated, an instance would be nonsensical. A class can be made noninstantiable by including a private constructor.

	// Noninstantiable utility class
	public class UtilityClass {
	// Suppress default constructor for noninstantiability
	private UtilityClass() {
	throw new AssertionError();
	}
	... // Remainder omitted
	}

view raw PrivateConstructor.java hosted with ❤ by GitHub

EJ-3 Enforce the Singleton Property with a Private Constructor or an Enum Type

Ref: Effective Java by Joshua Bloch

A singleton is simply a class the is instantiated exactly once, although making a class a singleton can make it difficult to test its clients, as it's impossible to substitute a mock implementation for a singleton unless it implements an interface that serves as its type.
Take a look at Misko Hevery's considerations about Singletons in terms of testability

• Root Cause of Singletons
• Where Have All the Singletons Gone?

In one approach, the member is a final field:

	// Singleton with public final field
	public class Elvis {
	public static final Elvis INSTANCE = new Elvis();
	private Elvis() { ... }
	public void leaveTheBuilding() { ... }
	}

view raw Singleton1.java hosted with ❤ by GitHub

In second approach, the public member is a static factory method:

	// Singleton with static factory
	public class Elvis {
	private static final Elvis INSTANCE = new Elvis();
	private Elvis() { ... }
	public static Elvis getInstance() { return INSTANCE; }
	public void leaveTheBuilding() { ... }
	}

view raw Singleton2.java hosted with ❤ by GitHub

In third and really interesting aproach is to make an Enum type with one element, marked as preferred approach By Mr. Bloch

	// Enum singleton - the preferred approach
	public enum Elvis {
	INSTANCE;
	public void leaveTheBuilding() { ... }
	}

view raw Singleton3.java hosted with ❤ by GitHub

A single-element enum type is the best way to implement singleton.

EJ-2 Consider a Builder When Faced with Many Constructor Parameters

Ref: Effective Java by Joshua Bloch

Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only required parameters, another with a single optional parameters, a third with two optional parameters, and so on...

	// Telescoping constructor pattern - does not scale well!
	public class NutritionFacts {
	private final int servingSize; // (mL) required
	private final int servings; // (per container) required
	private final int calories; // optional
	private final int fat; // (g) optional
	private final int sodium; // (mg) optional
	private final int carbohydrate; // (g) optional
	public NutritionFacts(int servingSize, int servings) {
	this(servingSize, servings, 0);
	}
	public NutritionFacts(int servingSize, int servings,
	int calories) {
	this(servingSize, servings, calories, 0);
	}
	public NutritionFacts(int servingSize, int servings,
	int calories, int fat) {
	this(servingSize, servings, calories, fat, 0);
	}
	public NutritionFacts(int servingSize, int servings,
	int calories, int fat, int sodium) {
	this(servingSize, servings, calories, fat, sodium, 0);
	}
	public NutritionFacts(int servingSize, int servings,
	int calories, int fat, int sodium, int carbohydrate) {
	this.servingSize = servingSize;
	this.servings = servings;
	this.calories = calories;
	this.fat = fat;
	this.sodium = sodium;
	this.carbohydrate = carbohydrate;
	}
	}

view raw TelescopingConstructorPattern.java hosted with ❤ by GitHub

Telescoping constructor pattern works, but it is hard to write client code when there are many parameters, harder still to read it.

An alternative way is to use JavaBeans patterns, creating instance with a parameterless constructor than calling setter method of each required parameters.  Unfortunately, the JavaBeans patterns has a serious disadvantages of its own, because construction is split across multiple calls, a JavaBean may be in an inconsistent state partway through its construction.

Better to use Builder Pattern, client calls setter-like methods on the builder object to set each optional parameter of interest and then calls parameterless build method to generate the object which is immutable.

	// Builder Pattern
	public class NutritionFacts {
	private final int servingSize;
	private final int servings;
	private final int calories;
	private final int fat;
	private final int sodium;
	private final int carbohydrate;
	public static class Builder {
	// Required parameters
	private final int servingSize;
	private final int servings;
	// Optional parameters - initialized to default values
	private int calories = 0;
	private int fat = 0;
	private int carbohydrate = 0;
	private int sodium = 0;
	public Builder(int servingSize, int servings) {
	this.servingSize = servingSize;
	this.servings = servings;
	}
	public Builder calories(int val)
	{ calories = val; return this; }
	public Builder fat(int val)
	{ fat = val; return this; }
	public Builder carbohydrate(int val)
	{ carbohydrate = val; return this; }
	public Builder sodium(int val)
	{ sodium = val; return this; }
	public NutritionFacts build() {
	return new NutritionFacts(this);
	}
	}
	private NutritionFacts(Builder builder) {
	servingSize = builder.servingSize;
	servings = builder.servings;
	calories = builder.calories;
	fat = builder.fat;
	sodium = builder.sodium;
	carbohydrate = builder.carbohydrate;
	}
	public static void main(String args[]){
	NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
	calories(100).sodium(35).carbohydrate(27).build();
	}
	}

view raw BuilderPattern.java hosted with ❤ by GitHub

In summary, the Builder pattern is a good choice when designing classes whose constructors or static factories would have more than a handful of parameters, especially if most of those parameters are optional. Client code is much easier to read and write with builders than with the traditional telescoping constructor pattern, and builders are much safer than JavaBeans. 

Ref: http://www.informit.com/articles/article.aspx?p=1216151&seqNum=2

EJ-1 Consider Static Factory Methods instead of Constructors

Ref: Effective Java by Joshua Bloch

In Item-1 of Effective Java, Mr. Bloch emphasize why and how it is important to use Static Factory methods instead of constructors.

Here is goofy and wasteful way to get Boolean instances

	public Boolean getFalse(){
	return new Boolean(false);
	}
	public Boolean getTrue(){
	return new Boolean(true);
	}

view raw StaticFactoryMethod2.java hosted with ❤ by GitHub

Here is shiny and frugally way to get immutable Boolean instance with static factory method

	public static Boolean valueOf(boolean b){
	return b ? Boolean.TRUE : Boolean.FALSE;
	}

view raw StaticFactoryMethod1.java hosted with ❤ by GitHub

Lets go over advantages of using static factory methods
1.) Unlike constructors, the have names. If parameters to a constructor do not describe object being returned, a static factory with well choosen name is easier to use and resulting client code easier to read.

	public BigInteger(int, int, Random){}
	//which returns a BigInteger that is probably prime
	//would have been better expressed as a static factory method
	public static BigInteger probablePrime(int, int, Random){}

view raw StaticFactoryMethod3.java hosted with ❤ by GitHub

Another example is multiple constructors with same signature as I met in stackoverflow.
Two constructors with same signature doing different things.

	public class Arquivo {
	private File diretorio = null ;
	public Arquivo(File dir){
	this.diretorio = dir;
	}
	public Arquivo(String dir){
	this( new File(dir) );
	}
	public Arquivo(String fileName){
	this( new File("./src/Data/"+fileName) );
	}
	}

view raw Arquivo.java hosted with ❤ by GitHub

Can be managed by using static factory methods.

	public class Arquivo {
	private File diretorio = null ;
	private Arquivo(File dir){
	this.diretorio = dir;
	}
	public static Arquivo newInstanceByFile(File dir){
	return new Arquivo(dir);
	}
	public static Arquivo newInstanceByFilePath(String path){
	return new Arquivo(new File(path) );
	}
	public static Arquivo newInstanceByFileName(String name){
	return new Arquivo(new File("./src/Data/"+fileName));
	}
	}

view raw Arquivo2.java hosted with ❤ by GitHub

2.) Unlike constructors, they are not required to create a new object each time they're invoked. This is demonstrated as in boolean example above and important to use system resources frugally by avoiding unnecessary instance creation.

3.) A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type. Mr Bloch exemplifies this advantage with Service Provider Framework pattern.

	public interface Provider {
	Service newService();
	}
	public interface Service {
	// Service-specific methods go here
	}
	public class Services {
	private Services() {} // Prevents instantiation (Item 4)
	// Maps service names to services
	private static final Map<String, Provider> providers = new ConcurrentHashMap<String, Provider>();
	public static final String DEFAULT_PROVIDER_NAME = "<def>";
	// Provider registration API
	public static void registerDefaultProvider(Provider p) {
	registerProvider(DEFAULT_PROVIDER_NAME, p);
	}
	public static void registerProvider(String name, Provider p) {
	providers.put(name, p);
	}
	// Service access API
	public static Service newInstance() {
	return newInstance(DEFAULT_PROVIDER_NAME);
	}
	public static Service newInstance(String name) {
	Provider p = providers.get(name);
	if (p == null)
	throw new IllegalArgumentException(
	"No provider registered with name: " + name);
	return p.newService();
	}
	}

view raw ServiceProviderFrameworkPattern.java hosted with ❤ by GitHub

Finally, he give a list of some common method names to statis factory methods.

• valueOf
• of
• getInstance
• newInstance
• getType
• newType

Often static factories are preferable, so avoid the reflex to provide public constructors without first considering static factories.

Interactive Regular Expression Tutorial

Here is a good interactive regular expression tutorial fun to try and study.