생성자와 this

4장에서는 new Member()로 객체를 만든 다음 member.email = ..., member.age = ...처럼 필드에 값을 하나씩 넣었습니다. 이 방식에서는 객체가 만들어진 순간부터 모든 필드가 채워질 때까지, 객체는 있지만 아직 쓸 수 없는 상태로 놓입니다. 그 사이에 다른 코드가 객체를 먼저 쓰거나, 필드 하나를 넣는 것을 잊어버리면 문제가 생깁니다.

앞 글의 Member는 생성자(constructor)로 이 문제를 피했습니다. 생성자는 new로 객체를 만들 때 실행되는 초기화 코드로, 필요한 값을 받아 필드에 넣는 일을 객체가 만들어지는 과정 안에서 끝냅니다. 이 글에서는 생성자가 없을 때 무슨 일이 생기는지부터 확인하고, 생성자를 선언하는 방법, 생성자 안에서 this가 하는 일, 생성자에서 값을 검사하면 무엇을 믿을 수 있게 되는지를 차례로 살펴봅니다.

필드 하나를 빠뜨리면

다음 프로그램은 생성자가 없는 Member를 만들고 나이만 넣은 뒤, 이메일을 대문자로 바꿔 출력하려고 합니다. email에 값을 넣는 줄은 어디에도 없지만, 필드는 지역 변수와 달리 대입하기 전에 읽어도 컴파일 오류가 나지 않습니다. 그래서 문제는 실행 중에 드러납니다.

public final class MissingInitialization {
    public static void main(String[] args) {
        Member member = new Member();
        member.age = 40;

        System.out.println(member.email.toUpperCase());
    }

    private static final class Member {
        String email;
        int age;
    }
}

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.toUpperCase()" because "<local1>.email" is null
	at MissingInitialization.main(MissingInitialization.java:6)

클래스와 인스턴스에서 본 것처럼 new Member()는 객체의 필드를 타입별 기본값으로 채웁니다. 참조형인 email은 null, int인 age는 0입니다. 이어서 age에는 40을 넣었지만 email에는 아무것도 넣지 않았으므로 null이 그대로 남습니다. 메시지의 <local1>은 1번 지역 변수, 즉 member를 가리킵니다. javac -g로 컴파일하면 이 자리에 변수 이름이 나옵니다.

여기서 실패한 것은 email 필드를 읽는 일이 아니라 toUpperCase()를 호출하는 일입니다. member.email을 읽는 것은 문제없이 성공해 null을 내놓습니다. 그 null에 대고 메서드를 호출하는 순간 예외가 납니다. 아래 그림은 객체를 만든 직후, 나이를 넣은 뒤, 이메일을 쓰는 순간의 필드 값을 차례로 보여 줍니다.

문제는 이 클래스 선언만 봐서는 어떤 필드를 꼭 채워야 하는지 알 수 없다는 데 있습니다. 생성자가 없으면 회원을 만드는 모든 곳에서 다음 세 줄을 빠짐없이, 올바른 순서로 써야 합니다.

Member member = new Member();
member.email = email;
member.age = age;

나중에 필수 필드가 하나 늘면 회원을 만드는 곳을 모두 찾아가 한 줄씩 추가해야 하는데, 하나를 놓쳐도 컴파일러는 아무 말을 하지 않습니다. 반면 필수 값을 생성자의 매개변수로 받으면, 값을 빠뜨린 호출은 컴파일되지 않습니다. 실수를 실행 중에 만나는 대신 컴파일할 때 발견하게 되는 것입니다.

생성자 선언하기

다음 Member는 이메일과 나이를 받는 생성자를 가집니다. main에서 new Member(...)의 괄호 안에 넣은 두 값과, Member 안에서 클래스 이름과 같은 이름으로 선언된 부분을 짝지어 보세요.

public final class ConstructorMember {
    public static void main(String[] args) {
        Member member = new Member("[email protected]", 40);
        System.out.println(member.describe());
    }

    private static final class Member {
        private String email;
        private int age;

        Member(String email, int age) {
            this.email = email;
            this.age = age;
        }

        String describe() {
            return email + "=" + age;
        }
    }
}

[email protected]=40

Member(String email, int age) { ... }는 메서드처럼 생겼지만 두 가지가 다릅니다. 이름이 클래스 이름과 똑같고, 반환 타입을 적는 자리가 비어 있습니다. void조차 적지 않습니다. 이 생성자가 있으면 new Member("[email protected]", 40)이 받은 두 값을 생성자에 넘기고, 생성자 본문이 그 값을 필드에 넣습니다. 그래서 describe()를 호출하는 시점에는 두 필드가 모두 채워져 있습니다.

생성자가 있으면 클래스와 인스턴스에서 본 new의 단계 가운데 생성자를 실행하는 단계가 실제로 일을 합니다. Member member = new Member("[email protected]", 40);은 다음 순서로 실행됩니다.

생성자 본문이 끝나야 4단계로 넘어가므로, member 변수가 객체를 가리키게 될 때는 이미 두 필드가 채워져 있습니다. 바깥 코드가 '반쯤 만들어진' 객체를 볼 틈이 없는 것입니다. 이 표는 이 장의 예제에 맞게 줄인 것으로, 필드 선언에 int age = 1;처럼 초깃값을 적었다면 그 대입은 3단계에서 생성자 본문보다 먼저 실행됩니다.

생성자에 반환 타입을 적으면 어떻게 될까요? 위 코드에서 생성자를 void Member(String email, int age)로 바꾸면 컴파일러는 이것을 이름이 우연히 Member인 평범한 메서드로 봅니다. 그러면 클래스에 선언한 생성자가 하나도 없게 되어, 컴파일러가 매개변수 없는 기본 생성자를 자동으로 넣습니다. 그래서 main의 new Member("[email protected]", 40)이 맞는 생성자를 찾지 못해 다음 오류가 납니다.

src/ConstructorMember.java:3: error: constructor Member in class Member cannot be applied to given types;
        Member member = new Member("[email protected]", 40);
                        ^
  required: no arguments
  found:    String,int
  reason: actual and formal argument lists differ in length
1 error

required: no arguments는 지금 쓸 수 있는 생성자가 인수를 받지 않는다는 뜻입니다. 생성자를 고친 줄이 아니라 생성자를 호출한 줄에서 오류가 나므로, 이 메시지를 보면 생성자 선언에 반환 타입이 붙지 않았는지 확인해 보세요. 생성자를 하나라도 선언하면 기본 생성자가 자동으로 생기지 않는다는 규칙은 다음 글에서 자세히 다룹니다.

생성자는 객체를 만들 때 new를 통해 한 번 실행될 뿐, 이미 만든 객체에 대고 메서드처럼 다시 호출할 수는 없습니다. member.Member("[email protected]", 50);이라고 쓰면 컴파일러는 그런 이름의 메서드가 없다는 cannot find symbol 오류를 냅니다. 만들어진 객체의 값을 나중에 바꿔야 한다면, 생성자와 같은 검사를 거쳐 값을 바꾸는 별도의 메서드를 만들어야 합니다. 다음 글에서 배울 this(...)는 생성자 안에서 같은 객체를 만드는 도중에 다른 생성자를 이어서 실행하는 문법이므로, 이미 만든 객체를 다시 초기화하는 것과는 다릅니다.

필드와 매개변수의 이름이 같을 때

생성자 안의 this.email = email;에서 this를 빼면 어떻게 될까요? 다음 프로그램의 생성자는 this 없이 대입합니다.

public final class MissingThisAssignment {
    public static void main(String[] args) {
        Member member = new Member("[email protected]", 50);
        System.out.println(member.email + "=" + member.age);
    }

    private static final class Member {
        String email;
        int age;

        Member(String email, int age) {
            email = email;
            age = age;
        }
    }
}

null=0

컴파일도 되고 예외도 없지만, 넘긴 이메일과 나이 대신 null=0이 출력됩니다. 생성자 안에는 email이라는 이름이 둘 있습니다. 하나는 객체의 필드이고, 다른 하나는 생성자의 매개변수입니다. 자바는 이름을 찾을 때 가장 안쪽 범위부터 찾으므로, 생성자 본문에서 email이라고만 쓰면 매개변수를 가리킵니다. 그래서 email = email;은 매개변수의 값을 같은 매개변수에 다시 넣을 뿐이고, 필드는 한 번도 건드리지 않습니다. 필드에는 2단계에서 받은 기본값 null과 0이 그대로 남습니다. 이처럼 안쪽 범위의 이름이 바깥 범위의 같은 이름을 가리는 것을 가려짐(shadowing)이라고 합니다.

필드를 가리키려면 this를 붙입니다. this는 지금 실행 중인 생성자나 메서드가 다루는 객체, 즉 현재 객체의 참조입니다.

Member(String email, int age) {
    this.email = email;
    this.age = age;
}

왼쪽의 this.email은 현재 객체의 필드이고, 오른쪽의 email은 생성자가 받은 매개변수입니다. 생성자를 이렇게 고치면 같은 프로그램이 [email protected]=50을 출력합니다. 아래 그림은 같은 입력 [email protected]과 50을 받은 두 생성자가 각각 어느 저장 공간에 값을 넣는지 비교합니다. this는 대입할 곳을 정확히 가리킬 뿐, 값이 올바른지 검사해 주지는 않습니다.

매개변수 이름을 inputEmail처럼 필드와 다르게 지으면 this 없이도 구분됩니다. 하지만 필드와 매개변수가 같은 정보를 뜻한다면 같은 이름을 쓰고 this로 구분하는 편이 둘의 대응을 더 분명하게 보여 줍니다. 자바 코드에서 생성자를 이렇게 쓰는 것이 흔한 이유입니다.

this는 생성자에서만 쓰는 것이 아닙니다. 인스턴스 메서드 안에서도 this.describe()처럼 현재 객체의 다른 메서드를 부르거나, printer.print(this)처럼 현재 객체를 다른 객체의 메서드에 인수로 넘길 때 씁니다. 다만 이름이 겹치지 않는 곳에서는 this.를 붙이지 않아도 같은 필드를 가리키므로, 모든 필드에 습관처럼 붙일 필요는 없습니다. static 메서드에는 현재 객체가 없으므로 this를 쓸 수 없고, 쓰면 non-static variable this cannot be referenced from a static context 오류가 납니다.

더 깊이: final 필드라면 컴파일러가 잡아 준다

앞의 실수는 필드에 final을 붙이면 컴파일 단계에서 드러납니다. Java 언어 명세(JLS §8.3.1.2)에 따르면, 선언할 때 값을 주지 않은 final 인스턴스 필드는 모든 생성자가 끝나기 전에 반드시 값을 한 번 받아야 합니다. MissingThisAssignment의 두 필드를 private final String email;과 private final int age;로 바꾸면, email = email;은 필드에 아무것도 넣지 않으므로 컴파일러가 생성자 끝에서 다음 오류를 냅니다.

lab/MissingThisAssignment.java:14: error: variable email might not have been initialized
        }
        ^
1 error

이 장의 예제 대부분이 private final 필드를 쓰는 이유 가운데 하나가 이것입니다. 생성 뒤에 바뀌지 않을 필드라면 final을 붙여 두는 것만으로 대입을 빠뜨리는 실수를 컴파일러가 대신 찾아 줍니다. final 필드의 다른 규칙은 6장의 final 변수·필드·상수에서 다룹니다.

생성자에서 값을 검사하기

생성자가 필수 값을 받게 만들면 값을 빠뜨리는 실수는 막을 수 있지만, 빈 이메일이나 130세 같은 잘못된 값까지 막지는 못합니다. 다음 프로그램의 생성자는 필드에 값을 넣기 전에 이메일과 나이를 차례로 검사하고, 규칙에 맞지 않으면 IllegalArgumentException을 던집니다. printCreation 메서드는 생성을 시도한 뒤 성공하면 created=를, 예외가 나면 그 메시지를 rejected= 뒤에 붙여 출력합니다.

public final class ValidatedConstructor {
    public static void main(String[] args) {
        printCreation("[email protected]", 40);
        printCreation("", 30);
        printCreation("[email protected]", 130);
    }

    private static void printCreation(String email, int age) {
        try {
            Member member = new Member(email, age);
            System.out.println("created=" + member.describe());
        } catch (IllegalArgumentException exception) {
            System.out.println("rejected=" + exception.getMessage());
        }
    }

    private static final class Member {
        private final String email;
        private final int age;

        Member(String email, int age) {
            if (email == null || email.isBlank()) {
                throw new IllegalArgumentException("email");
            }
            if (age < 14 || age > 120) {
                throw new IllegalArgumentException("age");
            }
            this.email = email;
            this.age = age;
        }

        String describe() {
            return email + "=" + age;
        }
    }
}

[email protected]=40
rejected=email
rejected=age

세 호출은 서로 독립적입니다. 첫 호출은 두 검사를 모두 통과해 필드에 값을 넣고, new가 돌려준 회원의 describe() 결과가 출력됩니다. 둘째 호출은 빈 이메일이라 첫 번째 if에서 "email" 예외가 납니다. 예외가 나면 생성자의 나머지 문장은 실행되지 않으므로 나이는 검사하지도 않습니다. 셋째 호출은 이메일 검사를 통과하지만 130이 120을 넘으므로 "age" 예외가 납니다. 두 경우 모두 printCreation의 catch가 예외를 잡아 메시지를 출력합니다.

예외가 나면 new 식은 객체의 참조를 돌려주지 않습니다. Member member = new Member(email, age);의 대입도 일어나지 않고, 실행은 곧장 catch로 넘어갑니다. 그래서 바깥 코드는 규칙을 어긴 회원 객체를 손에 넣을 방법이 없습니다. 검사를 필드 대입보다 앞에 둔 이유도 같습니다. 잘못된 값이 필드에 들어가는 일 자체가 없도록 하려는 것입니다. 아래 그림은 생성자 안에서 두 검사와 필드 대입이 어떤 순서로 이어지는지, 그리고 어디서 실패하면 참조를 받지 못하는지를 보여 줍니다.

이렇게 하면 'Member 객체가 있다면 그 이메일은 비어 있지 않고 나이는 14세부터 120세 사이다'라는 사실을 믿을 수 있습니다. 이 사실은 생성자라는 문법이 저절로 만들어 주는 것이 아니라, 이 생성자가 직접 검사하기 때문에 성립합니다. 그리고 final 필드라서 만든 뒤에 바뀌지도 않습니다. 그래서 describe()나 다른 메서드는 email이 null인지 매번 다시 확인할 필요가 없습니다. 회원이 만들어지는 길목 한 곳에서 검사했기 때문입니다.

사용자 입력을 받는 CLI라면 잘못 입력할 때마다 프로그램이 예외로 끝나면 안 됩니다. 그래서 printCreation처럼 입력을 처리하는 쪽에서 예외를 잡아 rejected 같은 안내로 바꿉니다. 생성자는 회원의 규칙을 지키고, CLI는 사용자와의 대화를 이어 가는 일을 맡는 것입니다. 예외를 언제 던지고 어디서 잡을지는 12장에서 자세히 다룹니다.

저장소가 회원을 만들 때

이제 저장소 MemberRegistry가 이메일과 나이를 받아 직접 회원을 만들게 해 보겠습니다. 이번에는 앞 글처럼 저장소가 isValid로 미리 검사하지 않고, 회원 생성을 시도한 뒤 생성자가 예외를 던지면 그것을 잡아 false를 돌려줍니다. 나이 규칙은 Member 생성자에, 용량 규칙은 저장소의 add에 둡니다. 용량 2인 저장소에 회원 세 명을 차례로 추가합니다.

public final class ConstructingMemberRegistry {
    public static void main(String[] args) {
        MemberRegistry registry = new MemberRegistry(2);

        System.out.println(registry.add("[email protected]", 40));
        System.out.println(registry.add("[email protected]", 50));
        System.out.println(registry.add("[email protected]", 30));
        System.out.println(registry.summary());
    }

    private static final class MemberRegistry {
        private final Member[] members;
        private int size;

        MemberRegistry(int capacity) {
            if (capacity <= 0) {
                throw new IllegalArgumentException("capacity");
            }
            this.members = new Member[capacity];
        }

        boolean add(String email, int age) {
            if (size == members.length) {
                return false;
            }
            try {
                members[size] = new Member(email, age);
                size++;
                return true;
            } catch (IllegalArgumentException exception) {
                return false;
            }
        }

        String summary() {
            int total = 0;
            for (int index = 0; index < size; index++) {
                total += members[index].age();
            }
            return "count=" + size + ", total=" + total;
        }
    }

    private static final class Member {
        private final String email;
        private final int age;

        Member(String email, int age) {
            if (email == null || email.isBlank() || age < 14 || age > 120) {
                throw new IllegalArgumentException("invalid member");
            }
            this.email = email;
            this.age = age;
        }

        int age() {
            return age;
        }
    }
}

true
true
false
count=2, total=90

첫 두 요청은 용량이 남아 있으므로 회원을 만들어 0번과 1번 칸에 넣고, 그때마다 size를 0에서 1로, 1에서 2로 늘린 뒤 true를 돌려줍니다. 세 번째 요청은 size가 배열 길이 2와 같아 첫 if에서 바로 false를 돌려줍니다. 이때는 Member 생성자가 아예 호출되지 않습니다. 저장된 회원은 두 명뿐이므로 요약은 count=2, total=90입니다.

add 안의 순서가 중요합니다. members[size] = new Member(email, age);에서는 오른쪽의 생성자가 정상적으로 끝나야 배열 칸에 대입이 일어나고, 그다음 줄에서야 size가 늘어납니다. 생성자가 예외를 던지면 대입도 size++도 건너뛰고 catch로 넘어가므로, 배열과 size는 요청 전과 똑같이 남습니다. 예를 들어 빈 칸이 있는 저장소에 add("", 30)을 요청하면 false가 나오고 회원 수는 그대로입니다. 4장의 객체 배열로 회원 저장소 만들기에서 객체를 다 만든 뒤에 size를 늘렸던 것과 같은 원칙입니다. 아래 그림은 세 요청이 각각 어디까지 진행되는지, 그리고 생성자가 실패했을 때 어느 단계를 건너뛰는지 보여 줍니다.

이렇게 나누면 각 규칙이 그 규칙과 관련된 상태 바로 옆에 놓입니다. 이메일과 나이 규칙은 그 값을 가진 Member의 생성자에, 용량 규칙은 배열과 size를 가진 MemberRegistry의 add에 있습니다. 나이 범위가 바뀌어도 저장소는 고칠 필요가 없고, 저장 방식이 바뀌어도 회원의 규칙은 그대로입니다.

정리

• 생성자가 없으면 객체를 만든 뒤 필드를 하나씩 채워야 하고, 하나를 빠뜨려도 기본값이 남을 뿐 컴파일러는 알려 주지 않습니다. 필수 값을 생성자 매개변수로 받으면 빠뜨린 호출은 컴파일되지 않습니다.
• 생성자는 이름이 클래스와 같고 반환 타입이 없습니다. new는 필드를 기본값으로 채운 뒤 생성자 본문을 실행하고, 본문이 끝나야 참조를 돌려줍니다.
• 생성자나 메서드 안에서 이름만 쓰면 매개변수가 필드를 가립니다. this.필드로 현재 객체의 필드를 가리켜야 하며, final 필드는 대입을 빠뜨리면 컴파일 오류가 납니다.
• 생성자에서 값을 검사하고 실패하면 예외를 던지면, 규칙을 어긴 객체는 바깥으로 나가지 않습니다. 그 결과 만들어진 객체는 언제나 규칙을 지킨다고 믿을 수 있습니다.

연습 문제

1. 캠페인 이름과 목표 가입자 수를 반드시 받아야 만들 수 있는 SignupQuota 클래스를 작성하세요. 이름은 null이거나 공백일 수 없고, 목표는 1명부터 1,000명까지만 허용합니다. 규칙에 맞지 않으면 문제가 된 값의 이름("name" 또는 "targetCount")을 메시지로 하는 IllegalArgumentException을 던지세요. this로 필드와 매개변수를 구분하고, new SignupQuota("daily", 120)의 describe()가 daily=120을 돌려주게 하세요. 그런 다음 목표가 1, 1,000, 0, 1,001인 경우와 이름이 null인 경우, 그리고 이름과 목표가 둘 다 잘못된 경우에 각각 무엇이 출력될지 예상하고 확인하세요.
2. 다음 생성자를 가진 클래스로 new Member("[email protected]", 40).describe()를 출력하면 무엇이 나올까요? 두 필드가 모두 final이었다면 어떻게 될지도 설명하세요.

Member(String email, int age) {
    this.email = email;
    age = age;
}

3. ConstructingMemberRegistry의 add를 다음처럼 줄였다고 해 봅시다. 새로 만든 용량 2의 빈 저장소에 add("", 30)을 요청하면 무엇이 달라지고, 그 뒤 summary()를 호출하면 어떻게 될까요?

try {
    members[size++] = new Member(email, age);
    return true;
} catch (IllegalArgumentException exception) {
    return false;
}

public final class SignupQuotaConstructor {
    public static void main(String[] args) {
        SignupQuota goal = new SignupQuota("daily", 120);
        System.out.println(goal.describe());

        printCreation("daily", 1);
        printCreation("daily", 1_000);
        printCreation("daily", 0);
        printCreation("daily", 1_001);
        printCreation(null, 120);
        printCreation(" ", 0);
    }

    private static void printCreation(String name, int targetCount) {
        try {
            SignupQuota quota = new SignupQuota(name, targetCount);
            System.out.println("created=" + quota.describe());
        } catch (IllegalArgumentException exception) {
            System.out.println("rejected=" + exception.getMessage());
        }
    }

    private static final class SignupQuota {
        private final String name;
        private final int targetCount;

        SignupQuota(String name, int targetCount) {
            if (name == null || name.isBlank()) {
                throw new IllegalArgumentException("name");
            }
            if (targetCount < 1 || targetCount > 1_000) {
                throw new IllegalArgumentException("targetCount");
            }
            this.name = name;
            this.targetCount = targetCount;
        }

        String describe() {
            return name + "=" + targetCount;
        }
    }
}

daily=120
created=daily=1
created=daily=1000
rejected=targetCount
rejected=targetCount
rejected=name
rejected=name

다음 글

지금까지의 Member는 생성자가 하나뿐이었습니다. 다음 글에서는 생성자를 하나도 선언하지 않았을 때 컴파일러가 넣어 주는 기본 생성자의 규칙을 확인하고, 생성자를 여러 개 두면서도 검사와 대입은 한곳에 모으는 this(...) 호출을 배웁니다.