추상 클래스 & 봉인 클래스

📘 추상

사전적 의미의 추상(abstract)은 실체 간에 공통되는 특성을 추출한 것

추상 클래스

객체를 생성할 수 있는 클래스를 실체 클래스라고 한다면,
이런 클래스들의 공통적인 `필드`나 `메소드`를 추출해서 선언한 클래스를 추상 클래스라고 함

예시 
새, 곤충, 물고기는 동물이라는 공통적인 특성을 가짐
실체 클래스 =  새, 곤충, 물고기
추상 클래스 = 동물

추상 클래스는 `new 연산자`를 사용하여 객체를 직접 생성할 수 없다.

---

추상 클래스를 사용하는 이유 ❓

1. 공통 기능을 묶어서 코드 중복 방지

• 여러 자식 클래스에 공통된 필드나 메서드를 추상 클래스에 정의해서, 코드의 재사용성과 유지보수성을 높일 수 있음.

abstract class Animal {
    String name;

    void breathe() {
        System.out.println("숨을 쉰다");
    }

    abstract void sound(); // 공통 기능이지만 동작 방식은 다름
}

→ breathe()는 모든 동물이 공유하니까 추상 클래스에서 구현,
→ sound()는 동물마다 다르니까 추상 메서드로 선언해서 자식이 구현하게 함.

2. 자식 클래스가 반드시 구현해야 할 메서드 강제

• 추상 메서드를 선언하면, 자식 클래스는 그 메서드를 반드시 오버라이딩해야 해.
  → 통일된 인터페이스 제공이 가능해지고, 실수로 빠뜨릴 걱정이 없어짐.

abstract class Animal {
    abstract void sound(); // 무조건 오버라이딩해야 함
}

3. 객체 생성을 막고 설계 용도로만 사용

• 추상 클래스는 직접 객체로 만들 수 없음 → 오직 `상속 전용`
• 즉, 설계도처럼 "공통 규격"만 제공하고, 실제 동작은 자식이 채워넣는 구조

Animal a = new Animal(); // ❌ 에러! 추상 클래스는 인스턴스화 불가

4. 인터페이스보다 유연한 선택지

• 자바는 다중 상속이 안 되니까, 클래스는 하나밖에 상속 못 함.
• 하지만 인터페이스는 다중 구현이 가능하고, 추상 클래스는 상속만 가능함.
• 추상 클래스는 필드, 생성자, 일반 메서드까지 포함할 수 있어서, 공통 구현 로직이 많은 경우 인터페이스보다 유리함.

목적	설명
공통 기능 정의	자식 클래스에 공통된 코드 묶기
메서드 구현 강제	자식 클래스가 반드시 오버라이딩하게 함
설계용 클래스	직접 객체 생성 방지, 설계도로만 사용
인터페이스보다 실용적인 경우	필드나 구현 메서드가 필요한 경우 더 적합

---

Q. 추상 클래스가 추상 클래스를 상속할 수 있을까?

A. 추상 클래스는 다른 추상 클래스를 상속할 수 있음

왜 추상 클래스가 추상 클래스를 상속하는가?

1. 추상화 단계(레벨)를 나눌 수 있기 때문에

복잡한 시스템일수록 한 번에 모든 걸 정의하기보단, 점진적으로 추상화해서 계층적으로 구조화하는 게 좋음

abstract class Animal {
    abstract void makeSound();
}

abstract class Canine extends Animal {
    abstract void sniff();
}

class Dog extends Canine {
    void makeSound() { System.out.println("멍멍"); }
    void sniff() { System.out.println("킁킁"); }
}

 

• `Animal`: 모든 동물의 공통 기능 정의
• `Canine`: 개과 동물만의 공통 기능(sniff) 정의 (아직 구체적이지 않음)
• `Dog`: 구체적인 동물 → 여기서야 실제 메서드 구현!

---

2. 공통 로직은 추상 클래스가 나눠 갖기 때문

• 상위 추상 클래스: 정말 공통적인 추상 메서드 정의
• 하위 추상 클래스: 더 구체적인 역할 정의 + 일부 공통 메서드 구현
• 최하위 클래스(구현 클래스): 완전한 기능 구현

이렇게 하면 중복을 줄이면서도 역할을 명확히 분리할 수 있어.

항목	설명
가능 여부	✅ 추상 클래스는 추상 클래스를 상속할 수 있음
사용하는 이유	추상화 단계를 나누고, 역할을 계층적으로 분리하기 위해
장점	중복 제거, 구조적 설계, 유지보수 쉬움

 

---

봉인된 클래스

• 기본적으로 `final` 클래스를 제외한 모든 클래스는 부모 클래스가 될 수 있음
• JAVA 15 부터 무분별한 자식 클래스 생성을 방지하기 위해 봉인된(sealed) 클래스가 도입 됨

👇🏻 Person의 자식 클래스는 Employee와 Manager만 가능

public sealed class Person permits Employee, Manager { ... }

• sealed 키워드를 사용하면 permits 키워드 뒤에 상속 가능한 자식 클래스를 지정해야 함.
• 봉인된 Person 클래스를 상속하는 Employee와 Manger는 `final`, `non-sealed` 또는 또다른 봉인된 클래스인 `sealed` 키워드를 사용하여 선언해야 함

final	더 이상 상속 불가
non-sealed	봉인 해제

---

Q. non-sealed가 존재하는 이유?

봉인된 클래스는 자식 클래스를 한정하기 위해 사용하는데, 왜 자식에서 봉인을 해제하는가??

A. 제한을 하면서도 유연함을 허용하려는 설계 철학 때문에

1. 일부 자식만 제한하고, 일부는 자유롭게 하고 싶을 때

sealed 클래스를 만들면 자식 클래스를 명시적으로 제한 가능

public sealed class Shape permits Circle, Rectangle {}

만일 `Circle`은 더 이상 자식이 필요없고 `Rectangle`은 더 세분화된 타입이 있어야 한다면?

public final class Circle extends Shape {}       // 자식 불가
public non-sealed class Rectangle extends Shape {} // 자식 허용

👉 `non-sealed`은 "나는 자유롭게 확장될 수 있다" 라고 선언하는 것

즉, 부모는 전체적으로 자식들을 제한하지만, 특정 자식은 다시 열어둔다고 선택할 수 있게 만드는 구조

---

2. 상속 계층의 유연성을 위해

어떤 클래스 계층은 엄격하게, 어떤 클래스 계층은 유연하게 열어둘 필요가 있다.

예를 들어 Java의 sealed는 OOP에서 도메인 모델을 더 안전하게 설계하기 위한 도구인데,
모든 계층이 딱딱하게 닫혀 있으면 확장이 불가능해서 불편할 수 있음

sealed class Expr permits ConstExpr, VarExpr {}

non-sealed class VarExpr extends Expr {} // 다양한 변수 표현이 필요함
final class ConstExpr extends Expr {}     // 고정 상수는 확장 필요 없음

---

3. 권한을 일단 주고, 자식이 설계 책임을 가질 수 있도록 함

non-sealed은 부모가 "나는 너까지는 제어할게"
→ "그 다음은 네가 책임지고 알아서 열든 닫든 결정해" 라는 의도도 있다.

실무에서는 이렇게 하위 모듈 설계 책임을 넘기는 경우도 자주 있음

 

키워드	설명	상속 가능성	사용 목적	예시
sealed	자식 클래스를 제한하고 싶을 때 사용	명시한 클래스만 가능	상속 계층 제어, 보안성 향상	sealed class Shape permits Circle, Square {}
non-sealed	상속 제한을 해제하고 싶을 때 사용	누구든 상속 가능	유연한 확장 허용	non-sealed class Rectangle extends Shape {}
final	상속을 완전히 막고 싶을 때 사용	절대 불가	클래스 확장 금지	final class Circle extends Shape {}