Builder Pattern: Can't we simplify the creation of a builder object?

Just getting my head around the Builder pattern and I have a few (noob) questions. Mainly, why can't we just simplify the creation of a builder object?

Instead of this:

public final class Foo {

	private final String name;
	private final String description;

	private Foo(String name, String description) {
		this.name = name;
		this.description = description;
	}

	public String getName() {
		return name;
	}

	public String getDescription() {
		return description;
	}

	public static class Builder {
		private String name;
		private String description;

		public Builder setName(String name) {
			this.name = name;
			return this;
		}

		public Builder setDescription(String description) {
			this.description = description;
			return this;
		}

		public Foo build() {
			return new Foo(name, description);
		}

	}

}

//Use it
Foo f = new Foo.Builder().setName("test").setDescription("description").build();

Why not just use this?

public final class Foo {

    private String name;
    private String description;

    public String getName() {
		return name;
	}

	public String getDescription() {
		return description;
	} 

    public Foo setName(String name){
       this.name=name;
       return this; 
    }

    public Foo setDescription(String description){
       this.description=description;
       return this; 
    }
}

//Use it
Foo f = new Foo().setName("test").set("description");

I see maybe the first one is used when you want to build an immutable object, but other than that why can't I just use the second one instead? It's far simpler. Please provide examples as much as possible.

The builder pattern is useful when there are operations that are valid during construction that are not valid once the object is built.

Yes, this is most obviously the case for building immutable objects, but it also applies very often when only some aspects of the object are immutable. Common examples are:

• Often the identifier for an object (a person's name, for example) is specified during construction, but is not allowed to change after that;
• Injected dependencies, like the database to use, the log to use, etc., are often not allowed to change after construction;
• Factories and strategies are often not allowed to change after construction, because the object expects consistency across all their outputs.

Also, sometimes a setter on a valid object would have an effect, like dispatching an event, for example, that you don't want to happen during construction. You can sometimes get around that via complicated rules like "don't attach listeners until you're finished setting stuff up", but complicated rules are to be avoided.

Using your Second approach , i will be able to create a Object by doing.

> Foo f = new Foo().setDescription("description");

Which means, We java created a object in your system without a name.<br>
If we take another example which will be must self explanatory .

> Employee emp = new Employee ().setDescription("manager");

Which means i hired a manager in a company without even know name.

Basically with Build() , we can also make sure all the required member variable are provided while creating a object. We can even do basic vaidation if needed.<br>

public Foo build() {
				if(name == null){
					throw Exception();
				else
					return new Foo(name, description);
}

Your way is "JavaBeans Patterns", From effectice java item2："JavaBean Patterns" construction is split across multiple calls, a
JavaBean may be in an inconsistent state partway
through its construction. The class does not have the option of
enforcing consistency merely by checking the validity of the
constructor parameters. Attempting to use an object when it’s in
an inconsistent state may cause failures that are far removed from
the code containing the bug and hence difficult to debug. A related
disadvantage is that the JavaBeans pattern precludes the
possibility of making a class immutable and
requires added effort on the part of the programmer to ensure
thread safety. "Builder Pattern" is thread safe and more readable.

you can use lombok @Builder annotation to make a class "Builder Pattern".