[CH07] 객체지향프로그래밍4 (OOP)

본 포스팅은 자바의 정석 교재를 공부하며, 간단히 정리/기록 용도로 작성하였습니다. 혹여, 잘못된 내용이 있다면 지적해주시면 감사하겠습니다.

 

 

---

1. 추상 클래스(Abstract class)

[추상클래스란?]

추상 클래스(Abstract class) 는 추상 메서드(Abstract method)를 포함하고 있는 클래스로, 인스턴스를 생성할 수 없고 오로지 상속을 통해서만 완성이 가능하다. 키워드 abstract 를 앞에 붙여 완성할 수 있으며, 추상 메서드를 포함하고 있다는 것 외에는 일반 클래스와 완전히 동일하다.

 

[추상메서드란?]

추상 메서드는 메서드의 선언부만 구현된 것을 의미하며, 자세한 구현/동작은 상속받은 클래스에 따라서 달라진다. abstract void paly(int pos); 와 같이 선언할 수 있으며, 상속받은 클래스에서 자세히 구현한다.

 

[추상클래스의 작성]

abstract class Player{
    boolean pause;
    int currentPos;

    Player(){
        pause = false;
        currentPos = 0;
    }
    abstract void play(int pos);
    // abstract method
    abstract void stop();
    void play(){
        play(currentPos);
    }
    void pause(){
        if(pause)
        {
            pause = false;
            play(currentPos);
        }
        else {
            pause = true;
            stop();
        }
    }
}

위와 같이 작성된 추상 클래스가 있다. 이를 상속받은 CDplayer 클래스는 아래와 같이 구현할 수 있다.

class CDPlayer extends Player {
    void play(int currentPos) {
        /* */
    }

    void stop() {
        /* */
    }

    int currentTrack;

    void nextTrack() {
        currentTrack++;
    }

    void preTrack() {
        if (currentTrack > 1) {
            currentTrack--;
        }
    }
}

추상 메서드는 상속받는 클래스에서 구현해줄 수 있다. abstract 키워드를 사용하지 않고 그냥 빈 몸통을 만들어 놓아도 사실 동일하지만, 굳이 abstract 키워드로 명시하는 것은 자손 클래스를 작성할 때 프로그래머가 추상 메서드임을 인지하고 내용을 직접 구현해주어야 한다는 것을 놓치지 않을 수 있기 때문일 것이다.

 

아래의 클래스에서 공통된 부분을 뽑아내어 추상 클래스로 만들 수 있다.

class Marine{
    int x,y;
    void move(int x,int y){}
    void stop(){}
    void stimPack(){}
}
class Tank{
    int x,y;
    void move(int x,int y){}
    void stop(){}
    void changeMode(){}
}
class Dropship{
    int x,y;
    void move(int x,int y){}
    void stop(){}
    void load(){}
}

 

 위는 각각 move, stop 메소드와 x, y 변수가 공통적으로 들어가있으며, 이러한 경우에는 코드를 중복해서 작성하기 보다는 추상 클래스를 정의해서 조상 클래스로 만들어주면 코드가 보다 정돈될 수 있다. 공통된 부분을 가지는 추상 클래스를 Unit 으로 정의하고 상속받도록 하자. 공통적으로 들어가는 메소드를 추상 메소드로 정의하고, 각각의 자손 클래스에서 구체적으로 구현부를 작성해주면 된다.

 

abstract class Unit{
        int x,y;
        void move(int x,int y){}
        void stop(){}
}
class Marine{
    void move(int x,int y){}
    void stimPack(){}
}
class Tank extends Unit{
    void move(int x,int y){}
    void changeMode(){}
}
class Dropship extends Unit{
    void move(int x,int y){}
    void load(){}
}

ㄷ Unit 클래스타입의 참조변수 배열을 이용하여, 서로 다른 종류의 인스턴스를 붂어서 한번에 다룰 수 있다.

class source{
    public static void main(String[] args) {
        Unit[] group = new Unit[4];
        group[0] = new Marine();
        group[1] = new Tank();
        group[2] = new Dropship();
        
        for(int i = 0 ; i < group.length; i ++)
            group[i].move(100, 200);
    }
}

당연히도 Object 배열로 다룰 경우에는 move 함수를 사용할 수 없다. Object 클래스에는 move 메소드가 없기 때문이다.

2. 인터페이스(interface)

  추상클래스의 일종인 인터페이스는, 추상클래스보다 추상화 수준이 높기 때문에 일반 메소드, 멤버 변수를 멤버로 가질 수 없다. 오로지 추상 메서드와 상수만을 멤버로 가질 수 있다. 인터페이스는 클래스에서처럼 선언할 수 있다. 다만 class 키워드 대신 interface 를 사용해야 한다. 접근 제어자는 클래스와 동일하게 public, default 를 사용할 수 있다.

 

모든 멤버 변수는 public static  final 이어야 하고, 생략이 가능하다.

모든 메서드는 public abstract 이어야 하며, 생략할 수 있다.

다만, static 메서드와 default 메서드는 예외(JDK 1.8부터 적용됨.)

 

인터페이스의 모든 멤버에 대해서 위 사항은 적용되기 때문에, 제어자를 생략할 수 있는 것이다. 생략된 제어자는 컴파일 시 컴파일러에 의해 추가된다. 인터페이스의 메서드는 모두 추상메서드여야 하지만, JDK 1.8 버전부터 인터페이스에 static 메서드와 default 메서드를 허용할 수 있게 되었으나 현재 실무에서는 JDK 1.8 을 사용하지 않는 경우가 많기 때문에 이전 버전과 이후 버전에 대한 차이점을 잘 알고 있을 필요가 있다.

interface PlayingCard {
    public static final int SPADE = 4;
    final int DIAMOND = 3;
    static int HEART = 2;
    int CLOVER = 1;

    public abstract String getCardNumber();
    String getCardKind();
}

 인터페이스는 오직 인터페이스로부터만 상속을 받을 수 있고, 다중 상속이 허용된다. 인터페이스는 추상 클래스와 같이 그 자체로 인스턴스를 생성할 수는 없으며, 추상 클래스가 상속을 통해 추상 메서드를 완성시키는 것과 같이 인터페이스의 경우도 마찬가지인데 이를 extends 가 아닌 implements 를 사용한다는 것이 차이점이다. 구현하는 인터페이스의 메서드 중에서 일부 부분만 구현한다면, abstract 키워드를 앞에 붙여서 abstract class 로 선언해야 하며, 상속과 구현을 동시에 할 수도 있다.

class source {
    public static void main(String[] args) {
    Fighter f = new Fighter();
    
    if(f instanceof Unit)
        System.out.println("f is an instance of Unit Class");
    if(f instanceof Fightable)
        System.out.println("f is implemented from Fightable");
    if(f instanceof Movable)
        System.out.println("f is implemented from Movable");
    if(f instanceof Attackable)
        System.out.println("f is implemented from Attackable");
    if(f instanceof Object)
        System.out.println("f is implemented from Object");
    }
}
class Fighter extends Unit implements Fightable{
    public void move(int x, int y){
        // ...
    }
    public void attack(Unit u){
        // ...
    }
}
class Unit {
    int currentHP;
    int x;
    int y;
}
interface Fightable extends Movable, Attackable{ }
interface Movable { void move(int x, int y); }
interface Attackable { void attack(Unit u); }

  상속 받을 때, interface 는 implement 키워드를 사용했을 뿐이지 class 에서의 상속과 동일하다. 그러므로 interface 는 조상이라고 할 수 있으며, Movable interface 에 구현된 메소드인 move 함수를 보면 접근 제어자를 public 으로 설정하였다는 것에 주목해야 한다. 오버라이딩 할 때에는 조상의 메소드 보다 넓은 범위의 접근 제어자로 지정해야 하는데, Movable 인터페이스에 void move(int x, int y)라고 정의된 메소드는 public abstract 가 생략된 것이다. 그래서 이를 실제로 구현하는 Fighter 클래스에서는 void move(int x, int y)의 접근제어자를 public 으로 해야만 하는 것이다.

  

  인터페이스는 클래스에서와 달리 다중 상속이 가능하다고 했다. 다만 두 조상으로부터 상속받은 멤버 중 이름이나 선언부가 같고 구현 내용이 다른 경우가 발생할 수 있는데, 이러한 경우에는 자손 클래스에서 어떠한 조상의 메서드를 상속받는 것인지 알 수 없다. 한 쪽으로부터의 상속을 포기하거나, 이름 충돌이 발생하지 않도록 조상 클래스를 변경하는 것이 일반적인 대응이다. 그래서 이러한 다중상속은 득보다 실이 더 크다고 판단하였기 때문에 java 에서는 허용하지 않았다. C++ 에서는 허용한다. 여튼 자바는 다중 상속을 허용하지 않는 것이 하나의 대표적인 단점으로 작용하는데, 이를 인터페이스의 다중 상속을 허용함으로써 어느정도 대응할 수 있었지만 실제로 자바에서 인터페이스로 다중상속을 구현하는 경우는 잘 없다고 한다. 

 

  인터페이스는 static 상수만 정의할 수 있기 떄문에 조상 클래스의 멤벼 변수와 충돌하는 경우가 거의 없고, 충돌된다고 하더라도 클래스 이름을 붙여서 구분이 가능하다. 추상 메서드는 구현 내용이 전혀 없기 때문에 조상 클래스의 메서드와 선언부가 일치하는 경우에는 조상 클래스 쪽의 메소드를 상속받으면 되기 때문에 문제가 발생하지 않는다. 허나 이렇게 하면 충돌은 피하지만 다중 상속의 장점은 잃는다. 만약에 두 개의 클래스로부터 상속을 받아야만 하는 상황이 발생한다면, 비중이 높은 클래스를 상속받고 나머지 한 클래스는 내부에 멤버로 포함시키거나 필요한 부분을 뽑아서 인터페이스로 구현하는 것이 좋다. TVCR 이라는 클래스를 TV와 VCR 로부터 모두 상속받도록 만들기 위해서는, 비중이 높은 클래스인 TV 를 상속받도록 하고, VCR 클래스와 동일한 메서드를 가지는 interface 인 IVCR 을 만든 다음 아래와 같이 구현하는 것이 좋다.

public class TVCR extends TV implements IVCR{
    VCR vcr = new VCR();
    public void play() {
        vcr.play();
    }
    public void stop() {
        vcr.stop();
    }
    /*
    ...
     */
}

새로 메서드를 작성해야 하는 부담은 있지만 VCR 클래스의 인스턴스를 사용하여 쉽게 다중 상속을 구현할 수 있다. 또한 VCR 클래스의 내용이 바뀌어도 변경된 내용이 TVCR 클래스에도 자동으로 반영된다. 인터페이스를 사용하지 않고 그냥 VCR 클래스를 TVCR 클래스에 포함시켜서 구현할 수 있지만, 인터페이스를 활용함으로써 다형적 특성을 이용할 수 있다는 것이 장점이다.

 

  자손 클래스의 인스턴스는 조상 클래스 타입의 참조 변수로 참조하는 것이 가능하다. 인터페이스도 클래스의 조상이라고 할 수 있기 때문에, 인터페이스 타입의 참조 변수로 구현한 클래스의 인스턴스를 참조할 수 있고, 형 변환 또한 가능하다. interface Fightable 을 Fighter class 가 구현한 경우, Fightable f = (Fightable)new Fighter(); 혹은 Fightable f = new Fighter(); 와 같이 참조하는 것이 가능하다. 그럼로 인터페이스는 메서드의 매개변수 타입으로 사용가능하다.

 

void attack(Fightable f){ ... }

 

 인터페이스 타입의 매개변수를 둔다는 것은 메서드를 호출할 때, 해당 인터페이스를 구현한 클래스의 인스턴스를 매개변수로 제공해야 한다는 것을 의미한다. 그래서 위의 attack 메서드를 호출할 때에는 매개변수로 Fightable 인터페이스를 구현한 클래스의 인스턴스를 넘겨주어야 한다는 것이다. Fightable 인터페이스를 구현한 Fighter 클래스가 있다고 치자. 그러면 attack 메서드의 매개변수로 Fighter 인스턴스를 넘겨줄 수 있다. 그말은 즉슨 attack(new Fighter()) 와 같이 할 수 있다는 것이고, 마찬가지로 리턴 타입으로 인터페이스의 타입을 지정하는 것 또한 가능하다. 리턴 타입을 인터페이스로 한다는 것은 해당하는 인터페이스를 구현한 클래스의 인스턴스를 반환한다는 것을 의미한다. 

interface Parseable{
    public abstract void parse(String fileName);
}

class ParserManager{
    public static Parseable getParser(String type){
        if(type.equals("XML")) {
            return new XMLParser();
        }else{
            Parseable p = new HTMLParser();
            return p;
            // return new HTMLParser();
        }
    }
}

class XMLParser implements Parseable{
    public void parse(String fileName){
        /* 
        * ...
        * */
        System.out.println(fileName + "- XML parsing completed.");
    }
}

class HTMLParer implements Parseable{
    public void parse(String fileName){
        /*
        ...
         */
        System.out.println(fileName + "-HTML parsing completed.");
    }
}

class ParserTest{
    public static void main(String[] args) {
        Parseable parser = ParserManager.getParser("XML");
        parser.parse("document.xml");
        parser = ParserManager.getParser("HTML");
        parser.parse("document2.html");
    }
}

위 코드를 보면 Parseable 인터페이스는 parsing 기능을 구현할 목적으로 abstract method parse(String fileName)을 정의하였다. XMLParser 클래스와 HTMLParser 클래스는 Parseable 인터페이스를 구현한 것이고, ParserManager 클래스의 getParser 메서드는 매개변수로 넘겨받는 type 의 값에 따라서 XMLParser 인스턴스 혹은 HTMLParser 인스턴스를 반환한다. 만약 새로운 버전의 XML 구문 분석기인 NewXMLParser 클래스를 추가해야한다면, ParserManager 클래스의 getParser 메서드에서 return new NewXMLParser(); 으로만 수정해주면 된다. 이러한 특징은 분산한경 프로그래밍에서 큰 장점으로 작용된다. 예를 들어, 서버단에서의 변경만 해도 사용자 컴퓨터의 프로그램의 변경 없이 업데이트가 가능할 것이다.

 

  이러한 인터페이스를 사용하는 이유와 장점을 정리해보자.

1. 개발 시간을 단축할 수 있다.

  인터페이스만 사용해서 프로그램을 작성하는 것이 가능하기 때문이다. 메서드 호출 부에서 메서드의 내용에 상관없이 선언부만 알면 된다. 동시에 다른 엔지니어가 인터페이스를 구현하는 클래스를 만들도록 하면, 효율적으로 개발할 수 있다.

 

2. 표준화가 가능하다.

  프로젝트의 기본 틀을 인터페이스로 작성을 먼저 한 다음에, 팀원들에게 구체적으로 구현하도록 함으로써 코드의 표준화가 가능하다.

 

3. 서로 관계없는 클래스들에게 관계를 맺어줄 수 있다.

  상속관계에 놓여있지도 않고 같은 조상클래스를 가지고 있지도 않은, 서로 아무런 관계도 없는 클래스들에게 인터페이스를 공통으로 구현하도록 함으로써 관계를 만들어 줄 수 있다.

 

4. 독립적인 프로그래밍이 가능하다.

  인터페이스를 사용함으로써 구현부와 선언부를 분리할 수 있으므로, 실제 구현에 독립적인 프로그램을 작성하는 것이 가능하며 클래스 간의 관계를 인터페이스를 이용하여 간접적인 관계로 변경해준다면 한 클래스의 변경이 다른 클래스에 영향을 주지 않는 독립적인 프로그래밍을 할 수 있다.

 

  특정 데이터베이스를 사용하는 클래스를 만들었지만, 추후에 다른 데이터베이스로의 변경을 요하는 상황이 있을 수 있다. 이때, 데이터베이스 관련 인터페이스를 이용하여 프로그램을 정의하였다면 프로그램을 변경하지 않더라도 데이터베이스의 종류를 바꾸는 것은 크게 어렵지 않은 일이다. 자바에서는 다수의 데이터베이스와 관련된 인터페이스를 제공하고 있어, 이를 이용하면 특정 데이터베이스에 종속되지 않는 프로그램을 작성할 수 있다.

class source{
    public static void main(String[] args) {
        Tank tank = new Tank();
        Dropship dropship = new Dropship();


        Marine marine = new Marine();
        SCV scv = new SCV();
        scv.repair(tank);
        scv.repair(dropship);
    }
}

interface Repairable{ } // interface

class Unit{
    int hitPoint;
    final int MAX_HP;
    Unit(int hp) {
        MAX_HP = hp;
    }
}

class GroundUnit extends Unit{
    GroundUnit(int hp){
        super(hp);
    }
}

class AirUnit extends Unit{
    AirUnit(int hp){
        super(hp);
    }
}

class Tank extends GroundUnit implements Repairable{
    Tank(){
        super(150);
        hitPoint = MAX_HP;
    }
    public String toString(){
        return "Tank";
    }
}

class Dropship extends AirUnit implements Repairable{
    Dropship(){
        super(125);
        hitPoint = MAX_HP;
    }
    public String toString(){
        return "Dropship";
    }
}

class Marine extends GroundUnit{
    Marine(){
        super(40);
        hitPoint = MAX_HP;
    }
}

class SCV extends GroundUnit implements Repairable{
    SCV(){
        super(60);
        hitPoint = MAX_HP;
    }
    void repair(Repairable r){
        if(r instanceof Unit){
            Unit u = (Unit)r;
            while(u.hitPoint != u.MAX_HP){
                u.hitPoint++;
            }
            System.out.println(u.toString() + " repairing completed");
        }
    }
}

  위와 같이 Marine, SCV, Tank, DropShip 클래스가 있다고 하자. Marine, SCV, Tank 는 GroudUnit 을 조상 클래스로 가지고 있고 Dropship 은 AirUnit 을 조상 클래스로 가지고 있다. 실제 스타크래프트 게임에서는 기계 유닛에 대하여 repair 기능을 수행할 수 있다. 이를 구현하려고 하다 보니, repair 메소드를 각각에 해당하는 만큼 오버로딩해야 하는 상황이 발생한다. 이는 효율적이지 않으며, 이러한 상황에서 인터페이스를 이용하면 각각의 클래스에 대한 상속관계를 유지하면서 공통점을 부여할 수 있다. Repairable 인터페이스를 정의한 다음 각각의 기계 유닛에 대하여 인터페이스를 구현하도록 정의하면 된다.  repair 메서드에서 r 매개변수는 Repairable 타입인데, Repairable 인터페이스는 정의된 멤버가 없기 때문에 r 으로는 할 수 있는게 아무도 없다. 그래서 instanceof 연산자를 이용하여 타입을 체크한 다음에 Unit 클래스에 정의된 멤버를 사용할 수 있도록 하였다. 

 

  그래서 인터페이스는 도대체 무엇인가? 

아래의 두 가지 사항을 염두에 두고 있어야 한다.

 

1. 클래스를 사용하는 쪽(User)과 클래스를 제공하는 쪽(Provider)이 있다.

2. 메서드를 사용(호출)하는 쪽(User)에서는 사용하려는 메서드(Provider)의 선언부만 알면 되고, 내용은 몰라도 된다.

 

class A{
    public void methodA(B b){
        b.methodB();
    }
}
class B{
    public void methodB(){
        System.out.println("MethodB()");
    }
}

class source{
    public static void main(String[] args) {
        A a = new A();
        a.methodA(new B());
    }
}

위와 같이 작성된 프로그램을 보면 클래스 B 의 methodB() 의 선언부가 바뀌면 클래스 A 도 변경되어야 하는 구조를 가진다. 이와 같이 직접적인 관계를 가지는 클래스는 Provider 이 변경되면 User 또한 변경이 불가피하다. 이러한 상황에서는 인터페이스를 이용하면 클래스 A가 클래스 B 를 직접적으로 호출하지 않고도 인터페이스를 매개체로 하여 접근하도록 하면, 클래스 B 의 변경 사항이 발생하더라도 클래스 A 는 변경하지 않아도 된다. 이와 같이 간접적으로 관계를 변경하려면 인터페이스를 이용해서 클래스 B 의 선언부와 구현부를 분리할 필요가 있다.

interface I{
    public abstract void methodB();
}

위와 같이 클래스 B의 메서드 B 를 추상화하여 정의하는 interface 를 만들어 준 다음, 클래스 B 에서 구현하도록 한다.

class A{
    public void methodA(I i){
        i.methodB();
    }
}
class B implements I{
    public void methodB(){
        System.out.println("MethodB()");
    }
}

이렇게 해주면 클래스 A 에서 클래스 B 를 사용하지 않으므로, 간접적인 관계가 된다. 클래스 A 에서 여전히 클래스 B 의 메서드를 호출하고 있음에도 클래스 A 는 인터페이스 I 를 통해서 클래스 B 의 메서드에 접근하기 때문에 클래스 B 의 변경에 전혀 영향을 받지 않는다. 

 

  JDK1.8 부터 인터페이스에 추상 메서드 뿐만 아니라 디폴트 메서드와 static 메서드도 추가할 수 있다. static 메서드는 인스턴스와 관계 없는 독립적인 메서드이므로 사실 허용하지 않았을 이유가 크게 없었는데, JAVA 언어에 대한 단순화를 위해 인터페이스의 메서드는 모두 추상 메서드여야지 한다는 것에 대한 예외 사항을 두지 않은 것이라고 한다. 그래서 인터페이스와 관련된 static 메서드는 별도의 클래스에 만들었어야 하는데, 대표적으로 java.util.Collection 인터페이스가 있다. 이 인터페이스와 관련된 static 메서드들은, 인터페이스에는 추상 메서드만 선언할 수 있다는 규칙 때문에 Collection 이라는 클래스에 별도로 들어가게 되었다. 만약 초기부터 인터페이스에 추상 메서드 뿐만이 아니라 static 메서드를 추가할 수 있었더라면 Collection 클래스는 존재하지 않았을 것이다. 인터페이스에서도 역시 static 메서드의 접근 제어자는 public 으로 해야하며, 생략이 가능하다.

 

  인터페이스에 메서드를 추가한다는 것은 추상 메서드를 추가한다는 것이고, 이말은 즉슨 인터페이스를 구현하고 있는 모든 클래스들에서 새롭게 추가된 추상 메서드를 구현해야한다는 의미이다. 이러한 작업은 꽤나 복잡한 일이며, 인터페이스의 변경을 최대한 방지하려고 해도 어쩔수 없이 해야만하는 상황이 종종 발생한다. 이러한 상황에서 보다 쉽게 해결할 수 있게 하기 위해 JDK 설계자들은 디폴트 메서드(default method) 를 고안하였다. 디폴트 메서드를 인터페이스에 추가하더라도 해당하는 인터페이스를 구현하는 클래스의 변경은 필요하지 않는다. 앞에 default 키워드를 붙여서 메서드를 선언하면 되는데, 추상 메서드와는 달리 일반 메서드처럼 몸통 부분을 만들어주어야 하며 접근 제어자는 public 을 사용해야 하고 생략이 가능하다. 인터페이스에 추상 메서드를 추가하는 대신 디폴트 메서드를 추가하면 해당 인터페이스를 구현한 클래스를 변경하지 않아도 되는 것이다. 이는 조상 클래스에 새로운 메서드를 추가한 것과 동일하다. 다만 새롭게 추가한 디폴트 메서드와 기존 메서드의 이름 충돌이 발생하는 경우가 있는데 1. 여러 인터페이스의 디폴트 메서드 간 충돌이 발생하는 경우에는 인터페이스를 구현한 클래스에서 디폴트 메서드를 오버라이딩하여 해결한다. 2. 디폴트 메서드와 조상 클래스의 메서드 간 충돌이 발생하면, 조상 클래스의 메서드가 상속되고, 디폴트 메서드는 무시된다. 그냥 필요한 쪽의 메서드와 같은 내용으로 오버라이딩하도록 하자...

3. 내부 클래스(inner class)

  클래스 안에 선언한 클래스를 내부 클래스라고 하는데, 이렇게 함으로써 1. 내부 클래스에서 외부 클래스의 멤버들을 쉽게 접근할 수 있고, 2. 코드의 복잡성을 줄일 수 있다(캡슐화)는 장점이 있다. 내부 클래스로 만드는 것은 외부 클래스에서 잘 사용하지 않는 클래스여야 한다.

class A{
    class B{
        
    }
}

  내부 클래스는 선언 위치에 따라서 종류가 달라진다. instance class 는 외부 클래스의 멤버 변수 선언부에서 선언하며, 외부 클래스의 인스턴스 멤버처럼 다뤄진다. static class 도 동일하게 외부 클래스의 멤버 변수 선언부에서 선언하는데, 외부 클래스의 static 멤버와 같이 다루어진다. local class 는 외부 클래스의 메서드 혹은 초기화 블럭 내에서 선언되며, 선언 영역 내부에서만 사용이 가능하다. anonymous class 는 클래스의 선언 및 객체의 생성을 동시에 하는 일회용 익명 클래스이다.

 

  클래스에서는 default 와 public 접근 제어자만 사용이 가능하나 내부 클래스는 변수와 동일하게 public, default, private, protected 접근 제어자를 사용가능하다. 또한 abstract 와 final 과 같은 제어자도 사용이 가능하다. 내부 클래스를 정의할 때 유의해야 할 점은 만약 내부 클래스에서 static member 을 사용해야 하는 경우라면 내부 클래스도 static 으로 만들어주어야 한다는 것이다. 왜냐면 static member 라는 것은 객체 생성 없이 사용이 가능한 member 인데, 만약 내부 클래스가 static 이 아니라면 모순이 발생한다는 것이다. 내부 클래스가 static 이여야지 논리가 성립한다. 또한 중요한 것은 static 내부 클래스에서는 외부 클래스의 인스턴스 멤버에 접근할 수 없다. final static 은 상수이므로 허용한다.

 

• static 클래스에서만 static 멤버를 정의할 수 있다.
• 인스턴스 멤버 간 혹은 static 멤버 간에는 서로 직접 접근이 가능하다.
• static 멤버는 인스턴스 멤버에 직접적으로 접근할 수 없다. 굳이 접근하려면 객체를 생성해야만 한다. 
• 외부 클래스의 private 멤버도 내부 클래스에서는 직접 접근이 가능하다.
• 외부 클래스의 지역변수는 final 이 붙은 변수(상수)만 접근 가능하다. JDK1.8 부터는 final 생략이 가능해짐에 유의.
• 인스턴스 클래스의 인스턴스를 생서앟려면 외부 클래스의 인스턴스를 먼저 생성해야만 한다.
• static 내부 클래스의 인스턴스는 외부 클래스를 먼저 생성치 않아도 된다.
• 익명 클래스는 선언과 객체의 생성을 동시에 진행해서, 일회성으로 사용되는 클래스이다. 

---

References

http://www.yes24.com/Product/Goods/24259565

Java의 정석 - YES24