Clases en Java: definir campos, métodos y objetos

Una clase es un plano

Hasta ahora tu código ha vivido en métodos que pasan valores simples de un lado a otro. Una clase te permite agrupar datos relacionados y el comportamiento que opera sobre ellos en un único tipo con nombre. La clase es el plano; las cosas reales con las que trabajas son los objetos creados a partir de ella.

Una clase declara dos tipos de miembros: campos (los datos que guarda cada objeto) y métodos (lo que cada objeto puede hacer).

class Dog {
    String name;          // un campo: todo Dog tiene un nombre
    int age;              // otro campo

    void bark() {         // un método: comportamiento que tiene todo Dog
        System.out.println(name + " says woof!");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog();    // crear un objeto a partir del plano
        d.name = "Rex";       // asignar sus campos
        d.age = 3;
        d.bark();             // llamar a su método
    }
}

new Dog() construye un objeto en memoria y te entrega una referencia a él. d.name y d.bark() acceden a ese objeto concreto.

Cada objeto tiene su propio estado

El sentido de una clase es que puedes producir muchos objetos independientes, cada uno con sus propios valores de campo. Cambiar uno nunca afecta a otro.

class Dog {
    String name;

    void bark() {
        System.out.println(name + " barks");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog rex = new Dog();
        rex.name = "Rex";

        Dog bella = new Dog();
        bella.name = "Bella";

        rex.bark();     // Rex barks
        bella.bark();   // Bella barks
    }
}

rex y bella son dos objetos distintos. Cada uno tiene su propio name, por lo que cada bark() imprime un valor diferente. Estos datos por objeto se llaman estado de instancia.

Los campos y los métodos trabajan juntos

Los métodos dentro de una clase pueden leer y actualizar directamente los campos propios de ese objeto, sin necesidad de pasarlos como parámetros. El método ya "vive en" el objeto cuyos datos toca.

class Counter {
    int count;            // empieza en 0 por defecto

    void increment() {
        count++;          // actualiza el campo de este objeto
    }

    int value() {
        return count;
    }
}

public class Main {
    public static void main(String[] args) {
        Counter c = new Counter();
        c.increment();
        c.increment();
        c.increment();
        System.out.println(c.value());   // 3
    }
}

Fíjate en que increment() no recibe argumentos. Opera sobre el campo que pertenece al Counter sobre el que lo llamaste. Esta es la diferencia entre un método de clase y un método estático suelto: el método tiene un objeto implícito sobre el que actuar.

La palabra clave this

Dentro de un método, this es una referencia al objeto sobre el que se llamó al método. Normalmente no lo necesitas: escribir count ya significa this.count. Pero this se vuelve imprescindible cuando el nombre de un parámetro choca con el de un campo, lo cual ocurre constantemente en los setters y constructores.

class Point {
    int x;
    int y;

    void move(int x, int y) {
        this.x = x;       // this.x es el campo; x es el parámetro
        this.y = y;
    }

    void show() {
        System.out.println("(" + x + ", " + y + ")");
    }
}

public class Main {
    public static void main(String[] args) {
        Point p = new Point();
        p.move(4, 7);
        p.show();         // (4, 7)
    }
}

Un error habitual de principiante es escribir x = x; dentro de move. Eso solo asigna el parámetro a sí mismo y deja el campo intacto: el compilador no te avisará y tu objeto conservará en silencio sus valores antiguos. this.x = x; es lo que realmente actualiza el campo.

Valores por defecto de los campos y referencias null

Cuando creas un objeto, sus campos no quedan con basura: Java los inicializa con valores por defecto: 0 para los números, false para boolean y null para las referencias a objetos como String. Ese valor por defecto null es el origen de un fallo clásico.

class User {
    String name;          // sin asignar, así que vale null por defecto
}

public class Main {
    public static void main(String[] args) {
        User u = new User();
        System.out.println(u.name.length());   // NullPointerException
    }
}

u.name es null porque nadie lo asignó, así que llamar a .length() sobre él lanza una NullPointerException. Asigna siempre valores con sentido a un objeto antes de usar sus campos, que es precisamente el problema que resuelven los constructores.

Organizar el código en torno a clases

Los programas reales modelan su dominio como clases que mantienen juntos los datos y las operaciones sobre ellos. Aquí, una sola clase BankAccount guarda un saldo y controla cómo cambia:

class BankAccount {
    String owner;
    double balance;

    void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
        }
    }

    boolean withdraw(double amount) {
        if (amount > 0 && amount <= balance) {
            balance -= amount;
            return true;
        }
        return false;     // fondos insuficientes
    }
}

public class Main {
    public static void main(String[] args) {
        BankAccount acc = new BankAccount();
        acc.owner = "Sam";
        acc.deposit(100.0);
        boolean ok = acc.withdraw(30.0);

        System.out.println(acc.owner + " balance: " + acc.balance);  // 70.0
        System.out.println("withdrawal succeeded: " + ok);
    }
}

Los datos (balance) y las reglas para modificarlos (deposit, withdraw) viven en un mismo lugar. El código de otras partes pide a la cuenta que haga cosas en lugar de manipular sus números directamente: la base de un diseño limpio y fácil de mantener.

Siguiente: constructores

Asignar cada campo a mano después de new es tedioso y fácil de olvidar, y, como acabas de ver, un campo olvidado deja un null esperando para provocar un fallo. Un constructor te permite exigir e inicializar los campos de un objeto en el momento mismo de su creación, de modo que un BankAccount nunca pueda existir sin un propietario. De eso trata la siguiente página.