programmer.cwchoiit

참고 자료:

메서드 영역

메서드 영역은 프로그램을 실행하는데 필요한 공통 데이터를 관리한다. 이 영역은 프로그램의 모든 영역에서 공유한다.

• 클래스 정보: 클래스의 실행 코드(바이트 코드), 필드, 메서드와 생성자 코드등 모든 실행 코드가 존재한다.
• static 영역: static 변수들을 보관한다.
• 런타임 상수 풀: 프로그램을 실행하는데 필요한 공통 리터럴 상수를 보관한다. 예를 들어서 프로그램에 "hello"라는 리터럴 문자가 있으면 이런 문자를 공통으로 묶어서 관리한다. 이 외에도 프로그램을 효율적으로 관리하기 위한 상수들을 관리한다. (참고로 문자열을 다루는 문자열 풀은 자바 7부터 힙 영역으로 이동했다)

스택 영역

자바 실행 시, 하나의 실행 스택이 생성된다. 각 스택 프레임은 지역 변수, 중간 연산 결과, 메서드 호출 정보등을 포함한다. 

• 스택 프레임: 스택 영역에 쌓이는 네모 박스가 하나의 스택 프레임이다. 메서드를 호출할 때 마다 하나의 스택 프레임이 쌓이고, 메서드가 종료되면 해당 스택 프레임이 제거된다.

참고: 스택 영역은 더 정확히는 각 쓰레드 별로 하나의 실행 스택이 생성된다. 따라서 쓰레드 수 만큼 스택 영역이 생성된다. 쓰레드를 한 개만 사용하면 스택 영역도 하나이다. 쓰레드가 2개면 스택 영역도 두개이다.

힙 영역

객체(인스턴스)와 배열이 생성되는 영역이다. 가비지 컬렉션(GC)이 이루어지는 주요 영역이며, 더 이상 참조되지 않는 객체는 GC에 의해 제거된다.

메서드 코드는 메서드 영역에 존재한다.

자바에서 특정 클래스로 100개의 인스턴스를 생성하면, 힙 메모리에 100개의 인스턴스가 생긴다. 각각의 인스턴스는 내부에 변수와 메서드를 가진다. 같은 클래스로부터 생성된 객체라도, 인스턴스 내부의 변수 값은 서로 다를 수 있지만 메서드는 공통된 코드를 공유한다. 따라서 객체가 생성될 때, 인스턴스 변수에는 메모리가 할당되지만 메서드에 대한 새로운 메모리 할당은 없다. 메서드는 메서드 영역에서 공통으로 관리되고 실행된다. 정리하면 인스턴스의 메서드를 호출하면 실제로는 메서드 영역에 있는 코드를 불러서 수행한다.

스택과 큐

스택(Stack)

스택영역을 자바에서 가지고 있으면 스택이 어떤 구조로 이루어졌는지 이해해야 한다. 스택(Stack)은 쉽게 생각해서 위에만 구멍이 있는 통이라고 생각하면 된다.

스택에 블럭을 넣는다.

스택에 블럭을 뺀다.

어떤 구조인가? 가장 마지막에 넣은것이 가장 먼저 나오게 되는 후입선출(LIFO: Last In First Out) 구조를 가지고 있다.

큐(Queue)

큐는 위와 아래에 모두 구멍이 있는 통이라고 생각하면 된다.

어떤 구조인가? 가장 먼저 넣은 블럭이 가장 먼저 빠져나오는 선입선출(First In First Out) 구조이다. 이것을 큐라고 한다.

왜 이런 자료 구조를 알아야 하냐면 각자 필요한 영역이 있기 때문이다. 예를 들어 선착순 이벤트를 진행하는 프로그램을 만들 때 고객이 대기해야 한다면 큐 자료 구조를 사용해야 한다. 먼저 온 손님이 먼저 실행되어야 하니까. 그럼 프로그램 실행과 메서드 호출에는 스택 구조가 적합하다. 생각해보면 A라는 메서드가 있고 그 A라는 메서드는 내부에서 B라는 메서드를 호출한 결과를 받아 어떤 결과를 내는 로직이 있을 때 A를 호출하면 A가 B를 호출한다. 그럼 호출 순서는 A -> B 인데 뭐가 먼저 실행되어야 하나? B다. B가 실행되어야 A가 그 결과를 가지고 자기의 결과를 낼 수 있으니까. 그러니까 프로그램 실행 및 메서드 호출은 스택 구조가 적합하다. 그래서 자료구조에 대해서 이해하고 있는것은 중요하다. 적어도 스택이랑 큐 정도는.

위 내용을 코드로 예로 들어보자. 

public class Memory {
    public static void main(String[] args) {
        System.out.println("main start");
        method1(10);
        System.out.println("main end");
    }

    public static void method1(int m1) {
        System.out.println("method1 start");
        int cal = m1 * 2;
        method2(cal);
        System.out.println("method1 end");
    }

    public static void method2(int m2) {
        System.out.println("method2 start");
        System.out.println("method2 end");
    }
}

실행 결과:

main start
method1 start
method2 start
method2 end
method1 end
main end

명백하게 스택 구조를 이루고 있다는 게 보인다. 이 코드가 실행되는 동안 스택 영역은 어떤 변화가 일어날까?

• 처음 자바 프로그램을 실행하면 main()을 실행한다. 이 때 main()을 위한 스택 프레임이 하나 생성된다.
• main()은 method1()을 호출한다. method1() 스택 프레임이 생성된다.
  • method1()은 m1, cal 지역변수(매개변수 포함)를 가지므로 해당 지역 변수들이 스택 프레임에 포함된다.
• method1()은 method2()를 호출한다. method2() 스택 프레임이 생성된다. method2()는 m2 지역변수(매개변수 포함)를 가지므로 해당 지역 변수가 스택 프레임에 포함된다.

• method2()가 종료된다. 이때 method2() 스택 프레임이 제거되고, 매개변수 m2도 제거된다. method2() 스택 프레임이 제거되었으므로 프로그램은 method1()로 돌아간다. 물론 method1()을 처음부터 시작하는 것이 아니라 method1()에서 method2()를 호출한 지점으로 돌아간다.
• method1()이 종료된다. 이때 method1() 스택 프레임이 제거되고 지역변수(매개변수 포함) m1, cal도 제거된다. 프로그램은 main()으로 돌아간다.
• main()이 종료된다. 더 이상 호출할 메서드가 없고 스택 프레임도 완전히 비워졌다. 자바는 프로그램을 정리하고 종료한다.

스택 영역과 힙 영역이 같이 사용되는 경우

힙 영역에는 객체(인스턴스)가 사용된다고 했다. 그 점을 기억하면서 다음 코드를 보자.

Data

public class Data {
    private int value;

    public Data(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }

    public void setValue(int value) {
        this.value = value;
    }
}

DataMain

public class DataMain {
    public static void main(String[] args) {
        System.out.println("main start");
        method1();
        System.out.println("main end");
    }

    private static void method1() {
        System.out.println("method1 start");
        Data data = new Data(10);
        method2(data);
        System.out.println("method1 end");
    }

    private static void method2(Data data) {
        System.out.println("method2 start");
        System.out.println("data.value = " + data.getValue());
        System.out.println("method2 end");
    }
}

실행 결과

main start
method1 start
method2 start
data.value = 10
method2 end
method1 end
main end

실행 결과를 보면 스택 구조로 가장 마지막에 실행된 메서드가 가장 먼저 끝나는 구조로 진행됐음을 알 수 있다.

그럼 그림을 통해 좀 더 깊이 이해해보자.

• 처음 main() 메서드를 실행한다. main() 스택 프레임이 생성된다.

• main()에서 method1()을 실행한다. method1() 스택 프레임이 생성된다.
• method1()은 지역변수로 Data data1을 가지고 있다. 이 지역변수도 스택 프레임에 포함된다.
• method1()은 new Data(10)을 사용해서 힙 영역에 Data 인스턴스를 생성한다. 그리고 참조값을 data1에 보관한다.

• method1()은 method2()를 호출하면서 Data data2 매개변수에 x001 참조값을 넘긴다.
• 이제 method1()에 있는 data1과 method2()에 있는 data2 지역변수(매개변수 포함)는 둘 다 같은 x001 인스턴스를 참조한다.

• method2()가 종료된다. method2()의 스택 프레임이 제거되면서 매개변수 data2도 함께 제거된다.

• method1()이 종료된다. method1()의 스택 프레임이 제거되면서 지역 변수 data1도 함께 제거된다.

• method1()이 종료된 직후의 상태를 보자. method1()의 스택 프레임이 제거되고 지역변수 data1도 함께 제거되었다.
• 이제 x001 참조값을 가진 Data 인스턴스를 참조하는 곳이 더는 없다. 참조하는 곳이 없으므로 사용되는 곳도 없다. 결과적으로 프로그램에서는 더는 사용하지 않는 객체인 것이다. 이런 객체는 메모리만 차지하게 된다. GC는 이렇게 참조가 모두 사라진 인스턴스를 찾아서 메모리에서 제거한다. (참고로, 힙 영역 외부가 아닌 힙 영역 안에서만 인스턴스끼리 서로 참조하는 경우에도 GC의 대상이 된다.)

정리: 여기서 알아낸 사실은 지역변수는 스택 영역에서 관리되고 객체(인스턴스), 인스턴스 변수는 힙 영역에서 관리되는 것을 확인했다. 이제 나머지 하나가 남았는데 메서드 영역이다. 메서드 영역에서 관리하는 변수도 있다. static 변수가 그렇다. 

static 변수

static 변수는 다른 말로 정적 변수, 클래스 변수라고 표현한다. 이 변수를 사용하는 목적은 특정 인스턴스가 가지는 값이 아니라 클래스가 공통으로 사용하는 변수나 메서드를 작성하려고 할 때 사용한다. 그니까 인스턴스마다 달라지는 값이 아니라 모든 인스턴스가 다 동일한 값을 가진다는 소리다. 왜 필요할까? 특정 클래스가 공유하는 값을 전역으로 관리하고 싶은 경우가 있을 수 있기 때문이다. 

그리고 인스턴스마다 관리하는 변수가 아니란 소리는 이 static 변수는 힙 영역에서 관리하지 않는다는 말로 유추할 수 있다. 힙 영역은 객체(인스턴스)와 그 객체가 가지는 인스턴스 변수를 관리하는 곳이니까. 그래서 static 변수는 프로그램 전역에서 공통으로 사용되는 것들을 관리하는 메서드 영역에서 관리된다.

그래서 만약 Data3 이라는 클래스가 있고 그 클래스안에 클래스 변수 count가 있으면 인스턴스를 생성하면 해당 인스턴스와 인스턴스 변수는 힙 영역에서 관리되고 클래스 변수는 메서드 영역 내 static 영역에서 딱 1개만 생성되고 관리된다. 

이 상태에서 아무리 Data3 클래스의 인스턴스를 여러개 만들어도 다음과 같이 모두 같은 static 변수를 바라본다.

변수와 생명주기

• 지역변수(매개변수 포함): 지역 변수는 스택 영역에 있는 스택 프레임 안에 보관된다. 메서드가 종료되면 스택 프레임도 제거되는데 이때 해당 스택 프레임에 포함된 지역 변수도 함께 제거된다. 따라서 지역 변수는 생존 주기가 짧다.
• 인스턴스 변수: 인스턴스에 있는 멤버 변수 중 static이 붙지 않은 변수를 인스턴스 변수라고 한다. 인스턴스 변수는 힙 영역을 사용한다. 힙 영역은 GC(가비지 컬렉션)가 발생하기 전까지는 생존하기 때문에 보통은 지역변수보다 생명주기가 길다.
• 클래스 변수: 클래스 변수는 메서드 영역의 static 영역에 보관되는 변수이다. 메서드 영역은 프로그램 전체에서 사용하는 공용 공간이다. 클래스 변수는 해당 클래스가 JVM에 로딩되는 순간  생성된다. 그리고 JVM이 종료될 때까지 생명주기가 이어진다. 따라서 가장 긴 생명주기를 가진다.

static이 정적이라는 이유는 바로 여기에 있다. 힙 영역에 생성되는 인스턴스 변수는 동적으로 생성되고 제거된다. 반면에 static인 정적 변수는 거의 프로그램 실행 시점에 딱 한번 만들어지고 프로그램 종료 시점에 제거된다. 정적 변수는 이름 그대로 정적이다.

정적 변수 접근법

정적 변수는 클래스로부터 바로 접근도 가능하고 클래스의 인스턴스로도 접근이 가능하다.

Data.count // 가능 (클래스로부터 접근)
data.count // 가능 (인스턴스로부터 접근)

근데 인스턴스를 통한 접근은 관례상 추천하지 않는다. 이유가 뭘까? 코드를 읽는 사람은 이것을 보고 인스턴스 변수라고 생각하지 클래스 변수라고 생각하지 않기 때문이다. 관례는 따라야 좋기 때문에 관례이다. 

그리고 인스턴스로 접근을 한다고해도 결국 힙 영역에 해당 인스턴스로 가서 count를 찾는데 힙 영역에 없는 메서드 영역에 있는 변수구나!라고 판단해서 결국은 메서드 영역에 static 영역으로 가서 해당 변수에 접근한다.

물론, 해당 클래스 변수가 만들어지는 클래스 안에서는 그냥 접근하면 된다. 그냥.

static 메서드

static 메서드도 있는데 얘는 왜 있을까? 이유를 알아야 그 용도도 올바르게 사용할 수 있다. static 메서드는 해당 클래스의 인스턴스를 만들 필요가 없을 때 static 메서드를 만든다. 아래 코드를 보자.

Utils

public class Utils {

    public String decoration(String str) {
        return "*" + str + "*";
    }
}

UtilsMain

public class UtilsMain {
    public static void main(String[] args) {
        Utils utils = new Utils();
        String str = "Hello";
        String decoration = utils.decoration(str);

        System.out.println(str);
        System.out.println(decoration);
    }
}

Utils 클래스에 있는 메서드 decoration()은 문자열을 받아서 해당 문자열 앞뒤로 "*"을 붙여주는 메서드이다. 이것을 사용하는 코드가 UtilsMain이고 여기서 보면 Utils 클래스의 인스턴스를 생성한 후 해당 인스턴스로 decoration()에 접근한다. 근데, 인스턴스를 만들 필요가 있을까? 없다. 인스턴스를 사용하는 부분이 단 한개도 없다. 이럴 때 다음 코드를 아래처럼 변경해보자.

변경한 Utils

public class Utils {
    public static String decoration(String str) {
        return "*" + str + "*";
    }
}

변경한 UtilsMain

public class UtilsMain {
    public static void main(String[] args) {
        String str = "Hello";
        String decoration = Utils.decoration(str);

        System.out.println(str);
        System.out.println(decoration);
    }
}

기존 decoration() 메서드를 static 메서드로 변경하고 나니 인스턴스를 만들 필요없이 클래스 레벨로 바로 접근해서 사용했다. 코드 양도 줄고 불필요한 시간 낭비도 줄이고 가독성도 높아진 느낌이다. 이럴 때 static 메서드를 사용한다.

그러나, static 메서드는 언제나 사용할 수 있는 것이 아니다. 

정적 메서드 사용법

• static 메서드는 static만 사용할 수 있다.
  • static 메서드 안에서는 static 변수나 static 메서드만 사용이 가능하고 인스턴스 변수나 인스턴스 메서드는 사용할 수 없다.
• 반대로 어디서든 static 메서드를 호출할 수는 있다.
  • 접근 제어자만 허락한다면 어디서나 호출할 수 있다. 그러라고 만든 키워드가 static이니까.

아래 그림을 보면 이해가 바로 된다.

힙 영역에 있는 인스턴스 변수를 메서드 영역 내 static 영역에 있는 메서드가 알 길이 있을까? 참조값이 없으면 해당 변수에 접근 자체를 할 수 없다. 모르니까. 인스턴스 메서드는 메서드 영역에 있지만 static 영역에 있는게 아니라 이 또한 마찬가지로 어떤 메서드를 말하는지 참조값을 모르니 알 수 없다. 

참고 자료:

캡슐화는 객체 지향 프로그래밍의 중요한 개념 중 하나다. 캡슐화는 데이터와 해당 데이터를 처리하는 메서드를 하나로 묶어서 외부에서의 접근을 제한하는 것을 말한다. 캡슐화를 통해 데이터의 직접적인 변경을 방지하거나 제한할 수 있다.

캡슐화는 쉽게 이야기해서 속성과 기능을 하나로 묶고, 외부에 꼭 필요한 기능만 노출하고 나머지는 모두 내부로 숨기는 것이다.

캡슐화는 그러니까 두가지 파트로 나뉘어지는데, 1. 속성과 기능을 하나로 묶는다. 2. 외부에 꼭 필요한 기능만을 노출시키고 나머지는 숨긴다. 그럼 여기서 1번은 클래스 내 필드를 만들고 그 필드를 가지고 어떤 행위를 할 것인가에 대한 메서드를 정의하는 것으로 생각할 수 있다. 2번은 그 필드와 메서드를 접근 제어자를 통해 제한하는 것이다.

그럼 어떤것을 숨길까?

데이터를 숨겨라

객체에는 속성(데이터)과 기능(메서드)이 있다. 캡슐화에서 가장 필수로 숨겨야하는 것은 속성(데이터)이다. 예를 들어, Account라는 클래스가 있을 때 해당 클래스의 속성으로 'balance'라는 필드가 있으면 외부에서 이 필드에 직접적으로 접근이 가능하면 어디서나 잔고에 돈을 더하거나 뺄 수 있을것이다. 최악으로 가는 길이다. 자동차를 예시로 생각해보면 우리가 자동차를 운전할 때 자동차 부품을 다 열어서 그 안에 있는 속도계를 직접 조절하지 않는다. 단지 자동차가 제공해주는 엑셀이라는 기능을 사용해서 엑셀을 밟으면 자동차가 나머지는 다 알아서 하는 것이다.

객체의 데이터는 객체가 제공하는 기능인 메서드를 통해서 접근해야 한다.

기능을 숨겨라

객체의 기능 중 외부에서 사용하지 않고 내부에서만 사용하는 기능들이 있다. 이런 기능도 모두 감추는 것이 좋다. 예를 들어 자동차 엑셀을 밟는것만 알면 되는데 엑셀을 밟을 때 자동차가 하는 내부적으로 하는 행위를 우리가 안다고 자동차가 앞으로 가는것에 어떤 도움을 줄 수 있는가? 오히려 알면 독이 될 수도 있다. 

정리하면 데이터는 모두 숨기고, 기능은 꼭 필요한 기능만 노출하는 것이 좋은 캡슐화이다.

아래 캡슐화가 잘 된 코드로써 예를 들어보자.

Account

public class Account {
    private int balance;

    public Account(int balance) {
        this.balance = balance;
    }

    public int deposit(int amount) {
        balance += amount;
        return balance;
    }

    public int withdraw(int amount) {
        balance -= amount;
        return balance;
    }

    public void status() {
        System.out.println("현재 잔고: " + balance + "원");
    }
}

위 코드를 보면 은행 계좌 클래스임을 알 수 있고 필드로 'balance'라는 속성을 가진다. 그 필드는 외부에서 접근하지 못하는 'private'이다. 그리고 이 계좌라는 클래스에서 할 수 있는 행위는 입금, 출금, 잔고 상태 확인이 있을 수 있는데 각각의 기능은 외부에서도 사용가능 하도록 'public'으로 만들었다. 

그럼 이 Account 클래스를 가져다가 사용하는 코드를 보자.

AccountMain

public class AccountMain {
    public static void main(String[] args) {
        Account account = new Account(10000);

        account.deposit(5000);
        account.status();
        account.withdraw(1500);
        account.status();
    }
}

외부에서는 이 클래스의 객체를 만들어서 입금, 상태 확인, 출금, 상태 확인 기능을 차례대로 사용했다. 아무런 문제가 없다. 

이제 여기서 Account 클래스에 새로운 메서드를 만들것이다. 그 메서드는 외부에서 접근하지 못하는 기능이다. 

바로 입금이나 출금할 때 금액에 대한 유효성 검사를 하는 메서드이다.

private boolean isAmountValid(int amount) {
    return amount > 0;
}

그리고 그 메서드를 deposit(), withdraw()에 추가했다. 이렇게 내부에서만 사용하고 외부에서는 사용할 필요가 없는 기능은 숨기는 것이다. 

public int deposit(int amount) {
    if (isAmountValid(amount)) {
        balance += amount;
    } else {
        System.out.println("입금할 금액에 문제가 있습니다.");
    }
    return balance;
}

public int withdraw(int amount) {
    if (isAmountValid(amount) && balance > amount) {
        balance -= amount;
    } else {
        System.out.println("출금할 금액에 문제가 있습니다.");
    }
    return balance;
}

그럼 만약 이 메서드가 외부에서 접근이 가능하게 만들었다면 어떤 문제가 발생할까? 만약 Account를 만드는 개발자와 Account를 가져다 사용하는 개발자가 나뉘어져 있다면 사용하는 개발자는 다음과 같은 화면을 볼 것이다.

Account 객체를 만들었고 그 객체에 .을 찍어보니 다음과 같이 isAmountValid()라는 메서드가 있다. 그럼 가져다 사용하는 개발자는 생각할 것이다.

"음.. 내가 유효성검사를 한 후 입금이나 출금을 해야하나?"

너무나 합리적인 생각이다. 왜냐하면 public으로 접근 제어자를 설정했다는 의미는 외부에서 가져다가 사용하라는 뜻이다. 그래서 사용하는 개발자는 다음과 같은 끔찍한 코드를 짠다. 이미 내부에서 검사를 하는데 검사를 또 하고 있는것이다. 

또는 balance라는 필드를 public으로 변경해보자. 다음과 같이 사용하는 개발자는 balance라는 필드가 public으로 되어 있는것을 보고 생각한다. 

"아 내가 직접 잔고에 접근해서 잔고를 수정할 수 있겠구나?"

이것 또한 합리적이다. 마찬가지로 public으로 선언한 의미는 곧 외부에서 사용하란 소리이기 때문이다. 그럼 다음과 같이 끔찍한 코드가 작성이 가능해진다. 갑자기 사용자의 통장이 마이너스 통장이 되버린다.

이런것을 보고 캡슐화가 깨졌다고 표현한다. 그래서 접근 제어자와 캡슐화를 통해 데이터를 안전하게 보호하는 것은 물론이고, 사용하는 개발자 입장에서도 해당 기능을 사용하는 복잡도도 낮출 수 있다.

기본적으로 접근제어자 개념은 이해하고 있지만 클래스 레벨에 붙는 접근제어자 개념이 빈약한것 같아 기록한다.

우선 접근제어자는 총 4개가 있다. public, private, default, protected.

• public: 모든 외부의 접근을 허용
• private: 같은 클래스말고는 모두 허용하지 X
• default: 같은 패키지 안에서만 접근 허용
• protected: 같은 패키지 안에서만 접근 허용, 다른 패키지에서는 근본적으로 접근 불가하지만 상속받은 경우 접근이 가능

근데 클래스에서는 딱 2개 public과 default만 사용할 수 있다. 규칙이다. 그리고 그 외 규칙이 더 있다.

• 한 파일당 클래스 레벨에서 public은 무조건 딱 하나만 있을 수 있다.
• public 클래스와 파일명은 반드시 같아야 한다.
• default 클래스는 무한정 만들 수 있다.

진짜 어려울 게 하나도 없는 Package 개념에서 헷갈리는 딱 한가지만을 정리하고자 한다.

보통 패키지 구조는 다음과 같다.

• a
  • b
  • c
    • d
    • e
    • f

그리고 이 구조는 파일시스템에서 디렉토리의 구조와 백퍼센트 일치해야 한다. 

근데 이게 중요한게 아니고 이 구조라면 패키지는 몇개일까? 6개다.

a/a.b/a.c/a.c.d/a.c.e/a.c.f

즉, a안에 b가 있으면 a 패키지에 포함 아닌가요? 절대 아니다. a랑 a.b랑은 완전히 다른 패키지이다. 사람이 볼때야 저게 a안에 b처럼 보이지만 자바는 둘을 완전히 다른 패키지로 판단한다. 이것만 좀 주의. 그래서 실제로 만약 특정 클래스에서 a.c와 같은 구조를 가진 패키지 전체를 임포트해도 a.c.d 패키지안에 있는 클래스 사용하려면 따로 임포트해야 한다. 다음이 그 대답이다.

다음과 같은 패키지 구조를 가질 때 Order 클래스에서 User와 UserService를 임포트 할 땐 이렇게 한다. 

즉, user와 user.service는 완전히 다른 패키지라는 이야기이다. 이것만 헷갈리지말자!

생성자 개념은 익숙하다고 해도 오버로딩 시 this()를 사용하는 경우가 어떤 경우가 있는지 좀 명확하게 하기 위해 작성을 해본다.

예를 들어, 다음과 같은 코드가 있다고 해보자.

Student

public class Student {
    private String name;
    private int age;
    private int grade;

    public Student(String name, int age) {
        this.name = name;
        this.age = age;
        this.grade = 0;
    }

    public Student(String name, int age, int grade) {
        this.name = name;
        this.age = age;
        this.grade = grade;
    }

    public String getName() {
        return name;
    }

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

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public int getGrade() {
        return grade;
    }

    public void setGrade(int grade) {
        this.grade = grade;
    }
}

이 Student 클래스는 두 개의 생성자를 가지고 있다. 하나는 'name'과 'age'를 받는것과 나머지 하나는 'name', 'age', 'grade'를 받는것. 그리고 'grade'를 받지 않는 생성자를 사용할 땐 일단 점수는 0이라고 가정하고 'grade'에 0을 대입한다.

그런데 자세히 보면, 두 생성자가 거의 같은 코드이다. 이 중복을 어떻게 없앨 순 없을까? 그때 사용하는 것이 this()이다.

그래서 this()를 사용한 리팩토링 코드는 다음과 같다.

public Student(String name, int age) {
    this(name, age, 0);
}

public Student(String name, int age, int grade) {
    this.name = name;
    this.age = age;
    this.grade = grade;
}

이전 코드와 비교해보면 중복이 확실히 제거됐음을 알 수 있다. 이게 바로 this() 키워드이다.

주의

this()를 쓸 때 주의할 점이 있다. this()는 반드시 첫 줄에 있어야 한다. 예를 들어 다음과 같이 첫 줄이 아니면 에러가 발생한다.

public Student(String name, int age) {
    System.out.println("생성자 호출");
    this(name, age, 0);
}

그 에러 내용은 다음과 같다. 첫 줄에 적으라고 알려준다.

나는 이게 항상 헷갈렸다. 그래서 객체 지향 프로그램은 절차 지향이랑 뭐가 다른데? 비슷한거 같은데 왜 분리 해놓은거야? 

이 두 단어의 의미는 알고 있다. 두 단어의 의미는 다음과 같다.

• 절차 지향 프로그래밍: 순차적으로 프로그래밍이 실행된다. 작성한 코드의 순서에 중점을 두고 진행된다.
• 객체 지향 프로그래밍: 프로그램의 동작이나 특정 행위를 객체를 중심으로 코드를 작성하고 그에 맞춰 프로그램이 실행된다.

어떻게 다른걸까? 우선 객체 지향 프로그래밍을 이해하기에 앞서 절차 지향 프로그래밍이 뭔지 알아보자.

음악 플레이어 프로그램

다음과 같은 음악 플레이어 프로그램이 있다고 가정해보자.

• 플레이어를 실행/종료 할 수 있다.
• 플레이어의 볼륨을 줄이고, 키울 수 있다.
• 플레이어의 상태를 표시할 수 있다.

그래서 다음과 같이 실행 결과를 출력하는 프로그램이 있다고 생각해보자.

그러면 이런식으로 코드를 작성하면 될 것이다. 이 코드는 절차 지향으로 작성된 코드이다.

public class MusicPlayerMain {
    public static void main(String[] args) {
        int volume = 0;
        boolean isOn = false;

        // 플레이어 실행
        isOn = true;
        System.out.println("뮤직 플레이어를 실행합니다.");

        // 플레이어 볼륨 증가
        volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + volume);

        // 플레이어 볼륨 증가
        volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + volume);

        // 플레이어 볼륨 감소
        volume--;
        System.out.println("뮤직 플레이어의 볼륨을 감소합니다. 볼륨: " + volume);

        // 플레이어의 상태 표시
        if (isOn) {
            System.out.println("뮤직 플레이어: ON, 볼륨: " + volume);
        } else {
            System.out.println("뮤직 플레이어: OFF");
        }

        isOn = false;
        System.out.println("뮤직 플레이어를 종료합니다.");
    }
}

그런데 이 코드에서 사용되는 변수를 지역변수로 선언하는 게 아니라 클래스로 만들수도 있을 것이다. 그럼 다음과 같은 클래스가 하나 필요하다.

public class Player {
    boolean isOn;
    int volume;
}

그리고, 이 클래스의 객체를 만들어서 지역변수를 변경해보자. 이제 지역변수로 데이터를 정의하고 사용하는 게 아니고 클래스의 인스턴스로 데이터 묶음을 가지는 모양이 만들어졌다.

public class MusicPlayerMain {
    public static void main(String[] args) {
        Player player = new Player();

        // 플레이어 실행
        player.isOn = true;
        System.out.println("뮤직 플레이어를 실행합니다.");

        // 플레이어 볼륨 증가
        player.volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + player.volume);

        // 플레이어 볼륨 증가
        player.volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + player.volume);

        // 플레이어 볼륨 감소
        player.volume--;
        System.out.println("뮤직 플레이어의 볼륨을 감소합니다. 볼륨: " + player.volume);

        // 플레이어의 상태 표시
        if (player.isOn) {
            System.out.println("뮤직 플레이어: ON, 볼륨: " + player.volume);
        } else {
            System.out.println("뮤직 플레이어: OFF");
        }

        player.isOn = false;
        System.out.println("뮤직 플레이어를 종료합니다.");
    }
}

만들고 나니, 중복 코드가 많아보인다. 이 부분을 메서드로 추출해서 중복 코드를 최대한 없애보자. 다음과 같이 정말 깔끔한 코드가 됐다. 

public class MusicPlayerMain {
    public static void main(String[] args) {
        Player player = new Player();

        // 플레이어 실행
        on(player);

        // 플레이어 볼륨 증가
        volumeUp(player);

        // 플레이어 볼륨 증가
        volumeUp(player);

        // 플레이어 볼륨 감소
        volumeDown(player);

        // 플레이어의 상태 표시
        playerStatus(player);

        // 플레이어 종료
        off(player);        
    }

    public static void on(Player player) {
        player.isOn = true;
        System.out.println("뮤직 플레이어를 실행합니다.");
    }

    public static void off(Player player) {
        player.isOn = false;
        System.out.println("뮤직 플레이어를 종료합니다.");
    }

    public static void playerStatus(Player player) {
        if (player.isOn) {
            System.out.println("뮤직 플레이어: ON, 볼륨: " + player.volume);
        } else {
            System.out.println("뮤직 플레이어: OFF");
        }
    }
    
    public static void volumeUp(Player player) {
        player.volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + player.volume);
    }

    public static void volumeDown(Player player) {
        player.volume--;
        System.out.println("뮤직 플레이어의 볼륨을 감소합니다. 볼륨: " + player.volume);
    }
}

그러나, 이것은 정말 깔끔하게 잘 만들어진 절차 지향 프로그래밍이다. 무슨 말이냐면 데이터와 기능이 분리되어 있다. 정작 데이터를 관리하는 곳은 Player라는 클래스인데 그 클래스의 인스턴스(객체)의 데이터를 다루는 기능(플레이어 실행, 플레이어 종료, 볼륨 증가, 볼륨 감소)들은 모두 메인 메서드 안에 정의되어 있다. 이렇게 데이터와 기능이 분리되어 관리되는 방식이 대표적인 절차 지향 프로그래밍이다. 과거에는 모두 이런식으로 프로그램을 만들었다.

생각해보면 이상하다 볼륨을 높이고 줄이는 기능은 Player와 아주 아주 밀접하게 연관이 있는데 분리가 되어 있다는 사실이. 그래서 데이터를 관리하는 클래스안에 그 데이터에 대한 특정 행위를 하는 기능을 작성하는 것을 메서드라고 하고 그 메서드와 클래스를 한 곳에 관리하여 프로그램을 작성해보자. 이것이 곧 객체 지향 프로그래밍이다. 객체가 중심이 되는 것이다.

그럼 객체가 중심이 되도록 클래스에 데이터와 기능을 모두 같이 관리하도록 위 코드를 리팩토링해보자.

객체 지향 프로그래밍

Player

public class Player {
    private boolean isOn;
    private int volume;

    public void on() {
        this.isOn = true;
        System.out.println("뮤직 플레이어를 실행합니다.");
    }

    public void off() {
        this.isOn = false;
        System.out.println("뮤직 플레이어를 종료합니다.");
    }

    public void playerStatus() {
        if (this.isOn) {
            System.out.println("뮤직 플레이어: ON, 볼륨: " + this.volume);
        } else {
            System.out.println("뮤직 플레이어: OFF");
        }
    }

    public void volumeUp() {
        this.volume++;
        System.out.println("뮤직 플레이어의 볼륨을 증가합니다. 볼륨: " + this.volume);
    }

    public void volumeDown() {
        this.volume--;
        System.out.println("뮤직 플레이어의 볼륨을 감소합니다. 볼륨: " + this.volume);
    }
}

Main

public class MusicPlayerMain {
    public static void main(String[] args) {
        Player player = new Player();

        // 플레이어 실행
        player.on();

        // 플레이어 볼륨 증가
        player.volumeUp();

        // 플레이어 볼륨 증가
        player.volumeUp();

        // 플레이어 볼륨 감소
        player.volumeDown();

        // 플레이어의 상태 표시
        player.playerStatus();

        // 플레이어 종료
        player.off();
    }
}

위 코드를 보자. 얼마나 깔끔하고 아름다운가? 더 나아가서 이 코드는 아름답기만 할 뿐 아니라, 다른 클래스에서도 객체가 가질 수 있는 모든 기능을 사용할 수 있다. 예전 코드처럼 MusicPlayerMain 클래스에 정의한 기능들은 해당 클래스에서만 사용할 수 있다 (물론 접근제어자 개념과 MusicPlayerMain 클래스의 인스턴스를 만들어서 사용할 순 있지만). 그리고 큰 차이가 있는데, 데이터와 기능을 같은곳에서 관리하기 때문에 전달해줄 파라미터가 없다. 필요가 없다. 본인의 볼륨을 줄이고 키우면 되고 본인을 끄고 키면 되는데 무슨 파라미터가 필요하겠는가? 이렇게 객체가 중심이 되어 객체가 가지는 기능을 그 객체를 만들어내는 클래스에 정의하고 객체를 생성해서 객체가 행할 수 있는 행위들을 실행하는 방식을 객체 지향 프로그래밍이라고 한다.

그러니까 객체 지향 프로그래밍은 절차도 중요하지만 절차보다 객체 자체에 더 집중을 하는 방식. 다른 말로 음악 플레이어가 어떤 순서에 의해 어떤 동작을 했느냐보다 어떻게 음악 플레이어를 만들것인가?에 초점을 더 두는것을 객체 지향 프로그래밍이라고 생각하면 될 것 같다.

그리고 한 가지 더! 캡슐화라는 개념이 여기서 나오는데 플레이어를 구성하기 위한 속성과 기능이 마치 하나의 캡슐에 쌓여있는 것 같다. 이렇게 속성과 기능을 하나로 묶어서 필요한 기능을 메서드를 통해 외부에 제공하는 것을 캡슐화라고 한다. 그리고 이 결과 유지보수와 변경에도 용이해진다. 예를 들어, 플레이어의 'volume'이라는 필드명을 'playerVolume' 이라고 변경해야 할 때 이 플레이어를 가져다 쓰는 외부에 변경이 필요한가? 전혀 필요 없고 해당 클래스에서만 수정하면 된다. 서비스를 실행하는 쪽에서는 어떠한 변경도 필요가 없어진다는 뜻이다. 이게 객체 지향(좀 더 명확하게는 캡슐화)의 장점이라고 생각하면 되겠다.

클래스를 만들고 클래스의 인스턴스를 만들 때 해당 클래스의 멤버 변수는 값이 어떻게 들어갈까? 예를 들어 다음 코드를 보자.

public class Student {
    private String name;
    private int grade;
    
    public Student() {
    }

    public Student(String name, int grade) {
        this.name = name;
        this.grade = grade;
    }

    public String getName() {
        return name;
    }

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

    public int getGrade() {
        return grade;
    }

    public void setGrade(int grade) {
        this.grade = grade;
    }
}

Student 클래스가 있고 이 클래스의 객체 하나를 만들어보자. 

Student student = new Student();

이 인스턴스(객체)가 가지고 있는 멤버 변수들은 어떤 값을 가지는지 출력해보자.

public class StudentMain {
    public static void main(String[] args) {
        Student student = new Student();
        System.out.println("student name = " + student.getName());
        System.out.println("student grade = " + student.getGrade());
    }
}

출력 결과는 다음과 같다.

student name = null
student grade = 0

이렇듯, 클래스를 만들고 그 클래스의 객체를 만들 때 멤버 변수에 값을 집어 넣지 않으면 다음과 같이 초기화 값이 들어가게 된다. 숫자는 0으로 초기화가 되고 그 외 참조변수는 null이 들어간다. (String도 참조 변수다)

그럼 다음 클래스를 하나 더 만들어보자.

public class Department {
    private String name;
}

그리고 Student 클래스의 멤버 변수로 이 클래스를 넣어보자.

public class Student {
    private String name;
    private int grade;
    private Department department;

    public Student() {
    }

    public Student(String name, int grade, Department department) {
        this.name = name;
        this.grade = grade;
        this.department = department;
    }
    
    public String getName() {
        return name;
    }

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

    public int getGrade() {
        return grade;
    }

    public void setGrade(int grade) {
        this.grade = grade;
    }

    public Department getDepartment() {
        return department;
    }

    public void setDepartment(Department department) {
        this.department = department;
    }
}

이 상태에서도 위에서 생성한 인스턴스와 마찬가지로 Student 객체를 만들어보자.

Student student = new Student();

그리고 이렇게 실행해보자.

public class StudentMain {
    public static void main(String[] args) {
        Student student = new Student();
        System.out.println("student name = " + student.getName());
        System.out.println("student grade = " + student.getGrade());
        System.out.println("student department = " + student.getDepartment());
    }
}

출력 결과는 다음과 같다.

student name = null
student grade = 0
student department = null

Deparment 타입의 department, String 타입의 name 모두 참조변수이므로 null로 초기화된다. 그럼 여기서 이런 코드를 작성하면 어떻게 될까?

System.out.println("student department = " + student.getDepartment().getName());

여기서 NullPointerException이 발생한다. 그 이유는 student.getDepartment()가 null인데 null.getName()을 하면 당연히 어떤 주소의 객체에 해당하는 name을 가져와야 하는지 자바입장에서는 모르기 때문이다. 이게 NullPointerException이다. 이전 포스팅에서도 봤지만 null은 현재 가리키는 대상이 없을 때 주소대신 null을 넣게 된다. 그래서 가리키는 대상이 누군지 모르는데 어떻게 이름을 찾느냐? 라는것이다.

Null

우선 자바에서 null은 참조형 변수에만 사용할 수 있다. 참조형 변수는 메모리 상 주소(참조값)를 가지고 있는데 이 주소가 가리키는 곳 내부에 인스턴스, 배열 등등의 참조형 변수의 실체가 존재한다. 이 때 가리키는 대상이 없거나, 지금 당장 필요한게 아니라 이후에 가리키는 대상을 지정하고 싶을 때 null을 사용한다. 

참조형 변수에 null을 대입하는 것은 간단하게 다음과 같이 할 수 있다.

Student s = null;

그런데 만약, 이렇게 값도 없이 계속 쓰레기 데이터만 쌓이면 메모리는 감당할 수 있을까? 이를 해결하기 위해 자바는 GC라는 가비지 컬렉션을 제공한다.

GC (Garbage Collection)

자바는 JVM내 가비지 컬렉션이라는 녀석을 제공한다. 이 녀석이 하는 일은 더이상 그 무엇도 참조하고 있지 않는 객체를 메모리상에서 우리 대신 지워주는 역할을 한다. 아주 고마운 녀석이다. 어떤 객체가 있고 그 객체에 null을 대입했을 때 더이상 그 누구도 해당 객체를 참조하지 않는 상태라면 이 객체도 가비지에 해당하고 지역변수로 사용되는 변수가 다 쓰고 더 이상 사용되지 않을 때 이 또한 가비지에 해당한다. 그리고 이런 작업을 C언어에서는 개발자가 직접 메모리에서 삭제하는 코드를 작성해서 수행했다. 그런거보면 자바는 이를 대신해주니 엄청 고마운 녀석이라고 할 수 있겠다. 

그러면 이러한 의문이 들 수 있다. 그럼 가비지 컬렉션 말고 그냥 사용하고 바로 개발자가 없애는게 더 메모리 공간에 대해 효율적이 아닐까? 정답은 아니라고 볼 수 있다. 어떤 느낌으로 생각하면 좋냐면 데이터베이스에 READ 쿼리를 계속 수시로 하나씩 날리는 것과 한꺼번에 여러개에 대한 쿼리를 딱 한번 수행하는 느낌으로 생각하면 좋은 예시가 될 것 같다. 효율을 따지자면 가비지 컬렉션이 훨씬 더 좋을 수도 있다. 그리고 가비지 컬렉션 만드는 사람들은 진짜 엘리트들이다. 

참고 자료:

형변환

자바에서는 타입이라는 게 존재하는데 이는 다음과 같은 것들이다.

• int
• long
• double
• boolean
• ...

그리고 자바에서는 작은것을 큰 곳에 넣을 수 있다. 같은 정수를 다루는 int, long은 int보다 long이 더 큰 범위를 가진다. 즉, 담는 그릇 자체가 더 크단 이야기인데 이 말은 int로 선언한 변수의 값은 long에 담을 수 있다. 그리고 이는 내가 명시적으로 작성하지 않아도 자동 형변환이 된다.

그렇다면 큰 것을 작은 그릇에 담으려면 어떻게 될까? 컴파일 오류가 발생한다.

그러나, 죽어도 변경해야 한다면 또는 값의 유실이 생기더라도 변경을 해야겠다면 명시적 형변환을 할 수 있다.

그리고 이 결과는 iv라는 int형 변수에 담긴 값은 3.5가 아닌 3이 된다. 왜냐하면 int라는 타입은 정수만을 취급하기 때문이다. 그래서 형변환 시 이런 경우를 조심해야 한다. 

형변환 시 Overflow

그럼 만약에 int가 다룰 수 있는 최대 범위를 초과하는 long 변수의 값을 int 변수에 담으려고 하면 어떻게 될까? Overflow가 발생한다.

int 형 변수가 다룰 수 있는 범위는 -2147483648 ~ 2147483647이다. 그리고 '2147483648' 이 값은 그 범위를 초과하기 때문에 Overflow가 발생해서 값의 역이 일어난다. 그러니까 결론은 이런짓을 하면 안된다.

연산 시 형변환

연산을 할 때 기억할 대원칙 2가지가 있다.

• 같은 타입끼리 계산할 땐 같은 타입으로 계산이 된다.
• 다른 타입끼리 계산하면 더 큰 타입으로 자동 형변환이 일어난다.

이 두가지만 알면 연산 시 발생하는 에러는 고민할 필요가 없다. 예를 들어 이 결과를 예측해보자.

3을 2로 나누면 1.5가 되는데 과연 이 결과는 뭐가 나올까? 1이 된다. 그 이유는 int / int 연산은 같은 타입이므로 int로 계산이 된다. 그럼 1.5는 1로 변경이 된다. 그리고 그 값을 int 타입 변수에 대입을 하면 역시나 int = int이므로 int 타입으로 대입이 된다. 그러므로 1이라는 값이 나온다. 즉, 만약 1.5를 기대했다면 잘못된 코드인것.

그럼 다음과 같이 작성하면 될까? 이 결과는 1.0이 된다. 

왜냐하면 int(3) / int(2)는 같은 int 타입끼리의 계산이므로 1이 된다. 그리고 그 값을 double이라는 변수에 대입하는데 double이 int보다 더 큰 타입이므로 자동 형변환이 되어 1.0이 변수에 들어가게 된다.

그러면 도대체 1.5가 나오게 하려면 어떻게 해야하는 걸까? 3을 2로 나눌 때 double 타입으로 만들면 된다.

즉, 3이라는 int형 변수를 double로 형변환을 해서 3.0을 만들면 된다. 그럼 3.0 / 2가 되고 double / int가 되니까 더 큰 타입으로 자동 형변환이 된다. double(3.0) / double(2.0) 이 계산되어 1.5라는 값이 나오고 그 값이 double 형 변수에 담기기 때문에 1.5가 출력된다.

그래서 연산 시 형변환은 딱 두가지만 기억하자.

• 같은 타입끼리 계산할 땐 같은 타입으로 계산이 된다.
• 다른 타입끼리 계산하면 더 큰 타입으로 자동 형변환이 일어난다.

참고 자료:

정말 중요한 내용이다. JAVA는 언제나, 항상 (primitive type)변수의 값을 복사해서 대입한다. (항상 (reference type)변수의 참조값을 복사해서 대입한다) 이 말이 무슨 말이냐면 다음 소스 코드를 보자.

위 코드를 보면 add(int value)라는 메서드에 값을 주면 그 값에 10을 더하는 로직이 있다. 그럼 이 때 main 메서드에서 만든 

int value = 30; 에서 이 value의 최종적인 값은 무엇이 될까? 답은 30이다.

왜냐하면 위 문장 "자바는 항상 변수의 값을 복사해서 대입한다"를 생각하면 된다.

즉, main() 메서드에서 만든 value라는 변수와 add() 메서드에서 파라미터로 받는 value는 완전히 다른 변수이다. 굳이굳이 따지자면 add(int value)에서 value는 add() 메서드에서만 사용할 수 있는 지역변수라고 생각하면 된다. 그 지역변수에 main() 메서드의 value라는 변수에 들어있는 값만이 add() 메서드에 전달될 뿐이다. 즉, 값만을 복사해서 전달한 것.

그리고 이런 int, boolean, double, long 등과 같은 변수를 primitive type이라고 하는데 이와 반대로 String, Boolean, Double, Students, Products 등과 같은 변수를 reference type이라고 하는데 이런 변수들에 대한 대입은 해당 참조값(주소)을 복사해서 전달한다.

그래서 만약 위 메서드를 만든 의도가 전달한 value의 값을 10을 추가하고 그 추가된 값으로 main() 메서드 내에서 다음 로직을 계속 진행하고자 한다면 리턴값으로 돌려받아야 한다. 아래와 같이 말이다.

그리고, 또 다른 방법으로는 인스턴스를 사용하는 경우도 메서드 내부에서 변경을 그대로 가져가 사용할 수 있다. 다음과 같은 인스턴스가 있고 value라는 멤버 변수가 있다.

그러면 이렇게 인스턴스를 받아서 인스턴스의 값을 메서드 내부에서 변경하면 그 값이 메서드 밖에서도 적용이 된다. 

이는 위 내용과 일맥상통한다. 즉, 자바에서 대입은 항상 변수에 들어 있는 값을 복사한다. 인스턴스도 변수다. 변수인데 참조형(Reference Type)이다. 인스턴스 변수의 값은 메모리상의 주소를 가지고 있다. 주소에 가면 해당 인스턴스가 가지고 있는 필드(멤버 변수)를 담는 공간이 있다.

다시 한번 강조! 인스턴스도 변수고 인스턴스 변수에는 인스턴스 자체가 들어있는 게 아니라 위치를 가르키는 주소(인스턴스에서 참조값은 그 인스턴스의 주소가 된다)가 들어있다. 그래서 대입 시 인스턴스가 복사되는 게 아니라 참조값만 복사된다. 그래서 add(), main() 두 메서드에서 사용되는 인스턴스는 같은 인스턴스를 가리키게 되는 것.

그래서 헷갈리는 개념이 다음 코드를 보자.

Boolean bVal = false;

이거 보면 primitive type이 아니고 reference type이다. 그러면 이 값을 add() 메서드에 주면 이것도 참조값을 복사해서 주니까 주소를 복사해서 전달하고 add() 메서드 내부에서 변경이 일어나면 그게 밖에서도 적용되지 않을까? 라는 궁금증이 생길 수 있다. 결론부터 말하면 아니다. 왜 그러냐면 이것은 참조형 변수는 맞다. 그러나 이게 인스턴스인가? 아니다. 인스턴스라면 new로 만들어내야 한다. 즉, 이 reference type 변수 bVal의 참조값은 그대로 'false'이다. 주소가 아니다. 실제로 이 값을 찍어보면 된다. 만약 이 변수의 참조값이 메모리상의 주소라면 주소가 찍히는데 다음과 같이 값 그대로가 찍힌다. 

그래서 결론은 reference type이라도 변수가 담고 있는 값(참조값)이 메모리 상에 주소가 아닌 실제 값이라면 add() 메서드 내부에서 적용한 것은 add() 메서드 외부에서까지 반영되지 않는다.