Ile mniej? Dużo mniej. Jednak po kolei. W C# jeżeli tworzymy sobie obiekt reprezentujący jakieś dane to zazwyczaj robimy to tak:

Listing 1. klasa Customer w C#

using System;

public class Customer
{
    private int m_id = -1;

    public int ID
    {
        get
        {
            return m_id;
        }
        set
        {
            m_id = value;
        }
    }

    private string m_name = string.Empty;

    public string Name
    {
        get
        {
            return m_name;
        }
        set
        {
            m_name = value;
        }
    }
}

Generalnie można zdefiniować takie dziwne twory zamiast normalnych getterów i setterów.
W javie taka sama konstrukcja wygląda w następujący sposób:

Listing 2. klasa Customer w Javie

public class Customer {
	private long id;
	private String name;

	public long getId() {
		return id;
	}

	public String getName() {
		return name;
	}

	public void setId(long id) {
		this.id = id;
	}

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

}

Kodu jest trochę… jeżeli do tego dołożymy konstruktor (z założeniem, że settery zamieniamy na final), metody toString(), equals(), hashCode() to klasa nam tyje. Tyje bardzo ponieważ proste dwa pola „produkują” około 70 linii kodu. Zajebiście by było mieć feature podobny do tego z C#, czyli zdefiniować sobie bloki get i set… tyle tylko, że my piszemy w javie i jesteśmy lepsi. Nasze featury są bardziej zajebiste i generalnie bardziej tru Clean Code. My zrobimy to wszystko za pomocą JEDNEGO słowa. tak moi drodzy, te wszystkie nie fajne metody zamienimy na jedno słowo,a dokładnie na jedną adnotację, która „odwali” za nas brudną robotę związaną z tworzeniem tego kodu.

… a ósmego dnia stworzył Pan Lombok

Wykorzystamy do tego bibliotekę Lombok, która jest moim skromnym zdaniem najbardziej zajebistym rozwiązaniem w świecie Java od czasu pierwszej wersji Springa.
Dlaczego zapytacie… ano dlatego:

Listing 3. klasa Customer w Javie z Lombokiem

@Data
public class Customer {
	private long id;
	private String name;
}

Klasa z 20 linii „schudła” do 5. Do tego ma wszystkie wymagane w tej wersji funkcjonalności tzn. gettery i settery. Jeżeli zamienimy pola na final to otrzymamy jeszcze konstruktor, który będzie przyjmował parametry w kolejności deklaracji pól. Do tego nic, ale to nic się nie wyjebie. Ani Eclipse, ani NetBeans, ani Maven nie będa pyskować, że im kodu brakuje. Życie jest piękne…

No nie do końca oczywiście, ponieważ by to wszystko działało potrzeba Javy 6. Chyba jednak przesiadka na 6stkę to niska cena za ten piękny i czysty kod.