클래스 생성

추상화란 간단한 인터페이스 뒤에 디테일을 숨기는 것을 의미합니다 – String을 사용할 때 문자열 저장 방식을 알 필요는 없습니다. 좋은 설계는 문제를 클래스로 나누어 각 클래스가 하나의 개념만 담당하도록 합니다. 이 주제는 직접 작성하는 클래스에 대한 것입니다.

설계 선택은 코드가 올바른지, 가독성이 높고 재사용 가능한지에 영향을 미칩니다. 엔캡슐레이션 – 데이터를 프라이빗으로 유지하고 메서드를 통해만 노출하여 – 객체의 **상태(state)**를 오용으로 보호하고 내부 변경 시에도 클래스 사용자를 파산시키지 않게 합니다. 신중하게 지어진 이름, 단일 목적의 메서드 및 테스트는 **버그(bugs)**를 줄입니다.

설계는 코드 beyond의 책임도 수반합니다. 시스템 신뢰성(system reliability) – 프로그램이 실패 없이 예상대로 작업을 수행하는 것 – 은 프로그래머가 신중한 설계와 테스트를 통해 극대화해야 할 사항입니다. 프로그램은 사회, 경제, 문화에 실제적인 영향을 미치며 이는 유익한 측면과 해로운 측면을 모두 가질 수 있습니다. 또한 프로그램을 개발할 때는 법률적 및 지식재산권(ip) 문제가 발생하는데: 프로그래머들은 종종 **오픈 소스(open source)**로 공개되어 무료로 사용할 수 있는 코드를 재사용하지만, 해당 **라이선스(licence)**를 준수하고 **출처를 명시(give credit)**하며 다른 사람의 작품을 자신의 것으로 복제해서는 안 됩니다.

클래스는 세 부분으로 구성됩니다: 인스턴스 변수(instance variables) (필드(fields) – 객체의 데이터), 생성자(constructors) (객체 생성), 그리고 메서드(methods) (행동/behavior). 필드는 일반적으로 private; 메서드는 일반적으로 public:

public class Student {
    private String name;      // instance variable
    private int score;

    public Student(String n, int s) {   // constructor
        name = n;
        score = s;
    }
    public int getScore() { return score; }   // accessor
}

흔히 하는 실수. 생성자 내부에서 타입을 반복해서 선언하면 필드를 설정하는 것이 아니라 새로운 로컬(local) 변수를 선언하게 됩니다:

public Student(String n, int s) {
    String name = n;   // local variable: the field name stays null
    score = s;         // correct: sets the field
}

코드는 컴파일되지만, 이렇게 생성된 매 Student마다 name은 null과 같습니다.

**생성자(constructor)**는 클래스와 동일한 이름을 가지며 리턴 타입(return type)이 없습니다. new을 작성할 때 실행되며, 그 역할은 필드(initialize)를 초기화하는 것입니다. 클래스는 서로 다른 **파라미터 리스트(parameter lists) (오버로딩(overloading))**를 가진 여러 개의 생성자를 가질 수 있으며, 인수가 없는(no-argument) 생성자는 인수를 받지 않고 적절한 **기본값(defaults)**을 선택할 수 있습니다. 생성자 할당 전에 인스턴스 필드는 Java의 타입 의존적 초기 값, 예를 들어 0 for int 및 참조(references)에 대한 null을 가집니다.

풀이 예제/worked example. 두 개의 생성자를 가진 Point 클래스:

public class Point {
    private int x, y;

    public Point() {             // no-argument: the origin
        x = 0;
        y = 0;
    }
    public Point(int a, int b) { // two int parameters
        x = a;
        y = b;
    }
}

생성자가 설정하지 않는 필드는 기본값을 유지합니다: int에 대해 0, double에 대해 0.0, boolean에 대해 false, 객체에 대해 null. public void Point()을 작성하면 메서드가 생성되지, 생성자가 아닙니다: 생성자는 리턴 타입(return type)이 전혀 없으며, 심지어 void조차도 없습니다.

메서드는 서명, 반환 유형, 그리고 본체를 가집니다. **액세서(게터)**는 객체를 변경하지 않고 정보를 반환하며, **뮤테이터(세터)**는 필드를 변경합니다. 값을 반환하는 메서드는 모든 경로에서 올바른 type의 return이 있어야 하며, void 메서드는 아무것도 반환하지 않습니다.

public void setScore(int s) { score = s; }   // mutator
public String toString() { return name + ": " + score; }

풀이 예제/worked example. 점수에 b을 더하되 절대 100을 넘지 않도록 하고, 새로운 점수를 반환하는 뮤테이터 addBonus(int b)을 작성하십시오.

public int addBonus(int b) {
    score += b;
    if (score > 100) {
        score = 100;
    }
    return score;
}

1. 리턴 타입은 int입니다. 왜냐하면 메서드는 새로운 점수를 되돌리기 때문입니다.
2. 매개변수 b이 사용되었고, 필드 score이 변경되었으므로 이는 뮤테이터입니다.
3. 점수가 90일 때, addBonus(15)은 점수를 100로 설정하고 100을 반환합니다.

일반적인 실수는 if 내부에만 return을 두는 것입니다: if (score > 100) { return 100; }은 이후에 아무것도 없으면 컴파일되지 않습니다. 왜냐하면 다른 경로는 아무것도 반환하지 않기 때문입니다. 또 다른 실수는 반환하는 대신 결과를 출력하는 것입니다: 값을 반환하라는 요청을 받은 메서드는 단순히 System.out.println할 뿐이지 않아야 합니다.

객체를 메서드에 전달할 때, Java는 **참조(reference)**를 복사하므로 메서드는 같은(same) 객체에 작용하며, 해당 필드의 변경사항은 **호출자(callers)**에게 표시됩니다. (**원시형(primitives)은 **값에 의해 복사(copied by value)**되므로 Primitive에 대한 변경사항은 반영되지 않습니다.) 메서드는 또한 객체에 대한 **참조(reference)**를 **리턴(return)**할 수 있습니다. String은 **불변(immutable)**하기 때문에 이를 전달하는 것은 안전하지만, 변경 가능한(mutable) 객체를 전달하면 메서드가 이를 변경할 수 있습니다.

시험 기술: 메서드 내부에서 객체의 필드를 수정하면 원본에 영향을 미치지만, 재할당하는 것(param = new...)은 호출자에 영향을 주지 않습니다.

작업 예제. s이 점수 50를 가진 Student이라고 가정하고, tweak(s)을 호출해 봅시다:

public static void tweak(Student a) {
    a.setScore(100);          // (1) mutates the shared object
    a = new Student("Z", 0);  // (2) repoints the local copy only
    a.setScore(5);            // (3) changes only the new local object
}

라인 (1)은 객체 s이 가리키는 대상을 변경하므로 호출자는 이제 100을 봅니다. 라인 (2)는 메서드 자체의 레퍼런스 복사본이 새로운 객체를 가리키게 만들어 – 호출자의 s는 건드리지 않음 – 라인 (3)은 오직 그 새로운 객체에만 영향을 미칩니다. 호출 후, s.getScore()은 100: 변이는 유지되었으나 재할당은 유효하지 않았습니다.

정적(static/클래스) 변수는 static으로 표시되며, 클래스의 모든 객체에 의해 공유됩니다 – 총 한 개의 복사본만 존재(예: 생성된 객체 개수를 세는 카운터). 정적 메서드는 클래스에 속하며 인스턴스 필드를 직접 사용할 수 없습니다. 클래스 이름을 통해 접근합니다: Student.getCount().

풀이 예제. 새로운 Ticket마다 번호를 부여하여 1부터 세세요:

public class Ticket {
    private static int count = 0;   // one copy, shared
    private int number;             // one per object

    public Ticket() {
        count++;
        number = count;
    }
    public int getNumber() { return number; }
    public static int getCount() { return count; }
}

Ticket a = new Ticket(); Ticket b = new Ticket(); Ticket c = new Ticket(); 이후, a.getNumber()은 1이며, c.getNumber()은 3이고 Ticket.getCount()은 3입니다. 만약 count가 static가 아니라면, 각 객체는 고유한 count을 가지게 되며, 모든 티켓은 숫자 1이 되고, getCount은 static일 수 없습니다.

범위란 이름이 가시성 있는 영역을 의미합니다. 메서드 내에서 선언된 로컬 변수는 해당 메서드 내부에서만 존재하며, 파라미터는 해당 메서드 내에서만 유효하고, 인스턴스 변수는 객체 전체에서 가시성 있습니다. 접근 지정자는 클래스 간 가시성을 제어합니다: private(현재 클래스 전용) versus public(어디서나 사용 가능). 로컬 변수는 동일한 이름의 필드를 **음영 처리(shadow)**하여 버그의 원인이 됩니다.

해설 예제. 버그를 찾아보십시오:

public void setScore(int score) {
    score = score;
}

파라미터 score가 필드를 음영 처리하므로 양변 모두 파라미터를 의미합니다: 메서드는 파라미터를 자신에게 복사하고 필드는 절대 변경되지 않습니다. 해결책은 this.score = score;(다음 섹션 참고) 또는 다른 파라미터명인 newScore을 사용하는 것입니다.

this은 현재 객체를 가리키는 참조입니다. 동일한 이름의 매개변수로부터 필드를 구분하거나, 같은 객체의 다른 메소드를 호출하는 데 사용합니다:

public Student(String name, int score) {
    this.name = name;      // this.name is the field; name is the parameter
    this.score = score;
}

시험 기술: 컨스트럭터나 세터의 매개변수가 필드와 동일한 이름을 가질 때, 반드시 this.field = param을 작성해야 합니다 – this 없이 할당하면 아무런 유효한 작업이 이루어지지 않습니다.

• 메소드와 클래스를 이용한 설계: 데이터를 private 필드로 감싸고, 공개된 메소드를 통해 동작을 노출합니다.
• 객체와 그 클래스의 차이를 알고, 객체가 **값으로 전달(pass-by-value)**됨을 이해하십시오 – 매개변수는 참조의 복사본을 받으므로 메소드는 객체의 상태를 변경할 수 있지만, 매개변수를 재할당하면 caller에 영향을 주지 않습니다(Java는 참조로 전달되는 pass-by-reference가 없습니다).
• 배열과 ArrayList을 안전하게 순회하십시오 – 크기는 length vs .size()이며, 루프 중 제거 시 인덱스가 이동합니다.
• 재귀 메서드의 결과를 확인하기 위해 추적하십시오: 먼저 **기본 경우(base case)**를 찾고, 각 재귀 호출이 반환값에 도달하도록 따르십시오.(재귀 코드 작성은 시험 범위를 벗어납니다.)
• 상속 용어를 식별하십시오: 초기(superclass), 하위(subclass), 메서드 오버라이딩, 그리고 Object를 제외한 모든 Java 클래스가 Object의 직접 또는 간접 하위 클래스임을 알 것(상속 설계 및 구현은 시험 범위를 벗어납니다).