** 📌 1단계: 객체지향 프로그래밍(OOP)의 탄생 배경**

1️⃣ 기존 프로그래밍 방식(절차지향 프로그래밍)의 한계

초기의 프로그래밍은 절차지향 프로그래밍(Procedural Programming) 방식으로 작성되었다.

이 방식은 명령을 순차적으로 실행하며 프로그램을 구성하는 구조였다.

🔹 예제 (절차지향 방식의 햄버거 주문 코드)

print("주문을 받습니다.");
print("햄버거를 만듭니다.");
print("결제합니다.");

🔹 문제점

✅ 코드가 길어지면 유지보수가 어려움

✅ 반복되는 코드가 많아 비효율적

✅ 데이터와 함수가 분리되어 있어 복잡함

2️⃣ 객체지향 프로그래밍(OOP)의 등장

• *객체지향 프로그래밍(OOP)은 현실 세계를 프로그래밍으로 옮겨 **객체(사물)들이 서로 소통하는 방식을 구현한다.

즉, 프로그램을 “데이터 + 동작”을 가진 객체 단위로 구성하여, 재사용성과 유지보수성을 높이는 방식이다.

🔹 객체지향 방식 예제 (햄버거 주문 코드)

class Burger {
    void makeBurger() {
        System.out.println("햄버거를 만듭니다.");
    }
}

class Order {
    void takeOrder() {
        System.out.println("주문을 받습니다.");
    }
}

class Payment {
    void processPayment() {
        System.out.println("결제합니다.");
    }
}

🔹 OOP 방식의 장점

✅ 코드 재사용 가능 (객체화)

✅ 유지보수가 편리함 (모듈화)

✅ 확장성이 뛰어남 (새로운 기능 추가 용이)

3️⃣ OOP의 발전 과정

✅ 1960년대: 최초의 객체지향 언어 Simula 등장

✅ 1980년대: C++ 등장, 객체지향 개념이 본격적으로 도입

✅ 1995년: Java 탄생, 웹과 함께 대중화

✅ 2000년대 이후: Python, C#, Kotlin, Swift 등 다양한 객체지향 언어 등장

👉 객체지향 프로그래밍은 소프트웨어 개발을 더 쉽고, 효율적으로 만들기 위해 등장한 혁신적인 개념이다! 🚀

📌 2단계: 객체지향 프로그래밍(OOP)의 4가지 핵심 원칙

객체지향 프로그래밍(OOP)은 4가지 핵심 원칙을 기반으로 한다.

이 원칙들은 유지보수성과 확장성을 높이고, 보다 안정적인 프로그램을 만드는 데 도움을 준다.

---

1️⃣ 캡슐화(Encapsulation) - “데이터 보호 & 접근 제한”

🔍 개념

캡슐화는 객체의 내부 데이터를 보호하고, 외부에서는 제한된 방식으로만 접근하도록 만드는 기술이다.

즉, 데이터와 기능(메서드)을 하나의 객체로 묶고, 외부에서 직접 접근을 차단하는 개념이다.

⚠️ 왜 필요할까?

✔ 잘못된 데이터 수정 방지 (예: 체력이 -100이 되는 문제)

✔ 코드의 복잡성을 줄이고, 유지보수성을 높임

✔ 보안 강화 (중요한 데이터가 외부에서 직접 수정되지 않음)

📝 예제 코드 (캡슐화를 사용한 게임 캐릭터)

class Player {
    private int hp = 100; // 체력은 외부에서 직접 변경 불가

    public int getHp() {  // 체력 조회 (읽기 가능)
        return hp;
    }

    public void takeDamage(int damage) {  // 체력 감소 (쓰기 가능)
        if (damage > 0) {
            hp -= damage;
            if (hp < 0) hp = 0;  // 체력이 0 이하로 내려가지 않도록 설정
        }
    }
}

✔ private 키워드로 변수 hp를 숨김

✔ public 메서드(getHp(), takeDamage())를 통해 간접적으로 접근

---

2️⃣ 상속(Inheritance) - “코드 재사용”

🔍 개념

상속은 기존 클래스(부모)의 기능을 물려받아 새로운 클래스(자식)를 만드는 것을 의미한다.

즉, 공통된 기능을 부모 클래스에 정의하고, 이를 자식 클래스가 재사용하는 방식이다.

⚠️ 왜 필요할까?

✔ 중복 코드 제거

✔ 코드 유지보수 용이

✔ 새로운 기능 추가가 쉬움

📝 예제 코드 (동물 클래스 상속)

class Animal {  // 부모 클래스
    void eat() {
        System.out.println("먹는다!");
    }
}

// 🐕 강아지 클래스 (Animal을 물려받음)
class Dog extends Animal {
    void bark() {
        System.out.println("멍멍!");
    }
}

// 🐱 고양이 클래스 (Animal을 물려받음)
class Cat extends Animal {
    void meow() {
        System.out.println("야옹!");
    }
}

✔ Dog와 Cat은 Animal의 eat() 메서드를 상속받아 사용 가능

✔ 각 클래스에서 추가적인 기능(bark(), meow())을 정의

---

3️⃣ 다형성(Polymorphism) - “하나의 인터페이스, 다양한 구현”

🔍 개념

다형성은 같은 메서드를 여러 방식으로 구현할 수 있도록 하는 기술이다.

즉, 하나의 코드로 다양한 동작을 할 수 있도록 만든다.

⚠️ 왜 필요할까?

✔ 유연한 코드 작성 가능

✔ 확장성과 유지보수성이 뛰어남

✔ 같은 인터페이스로 여러 개의 객체를 다룰 수 있음

📝 예제 코드 (오버라이딩을 이용한 다형성)

class Animal {
    void speak() {
        System.out.println("동물이 소리를 낸다!");
    }
}

class Dog extends Animal {
    @Override
    void speak() {
        System.out.println("멍멍!");
    }
}

class Cat extends Animal {
    @Override
    void speak() {
        System.out.println("야옹!");
    }
}

public class Test {
    public static void main(String[] args) {
        Animal myPet = new Dog();
        myPet.speak();  // "멍멍!" 출력

        myPet = new Cat();
        myPet.speak();  // "야옹!" 출력
    }
}

✔ 부모 클래스 Animal의 speak() 메서드를 Dog와 Cat에서 각각 다르게 구현(오버라이딩)

✔ 같은 Animal 타입이지만 speak()가 실행될 때 다르게 동작 (다형성 구현)

---

4️⃣ 추상화(Abstraction) - “필요한 기능만 노출”

🔍 개념

추상화는 불필요한 세부 사항을 숨기고, 중요한 기능만 외부에 제공하는 개념이다.

즉, 객체의 내부 구현은 감추고, 핵심 기능만 정의하는 것이다.

⚠️ 왜 필요할까?

✔ 복잡한 내부 구조를 숨기고 간단한 인터페이스만 제공

✔ 유지보수성과 확장성이 뛰어남

✔ 코드의 가독성과 재사용성이 증가

📝 예제 코드 (추상 클래스를 활용한 추상화)

abstract class Car {
    abstract void drive();  // 🚗 "운전하는 방법"만 정함 (구현 X)

    public void stop() {
        System.out.println("자동차가 멈춘다.");
    }
}

class Tesla extends Car {
    @Override
    void drive() {
        System.out.println("전기차로 자율주행!");
    }
}

class Ferrari extends Car {
    @Override
    void drive() {
        System.out.println("V12 엔진으로 빠르게 달린다!");
    }
}

✔ Car 클래스에서 drive()를 추상 메서드로 선언 (구체적인 구현 X)

✔ 각 자식 클래스(Tesla, Ferrari)에서 drive()의 구체적인 동작을 구현

---

🎯 2단계 요약

OOP 원칙	설명	장점
캡슐화	데이터를 숨기고, 메서드를 통해 접근하도록 제한	데이터 보호, 유지보수 용이
상속	기존 클래스의 기능을 물려받아 재사용	코드 중복 제거, 확장 용이
다형성	같은 메서드를 다양한 방식으로 구현 가능	유연한 코드, 유지보수성 향상
추상화	내부 구현을 감추고, 핵심 기능만 제공	복잡성 감소, 인터페이스 단순화

📌 3단계: 클래스와 객체 - 설계도와 실체

객체지향 프로그래밍(OOP)의 핵심 개념은 클래스(Class)와 객체(Object) 이다.

클래스는 설계도(청사진) 역할을 하고, 객체는 클래스를 기반으로 생성된 실체(Instance) 이다.

---

1️⃣ 클래스(Class)란? - 설계도

클래스는 객체를 만들기 위한 틀(템플릿, 설계도) 이다.

즉, 객체가 어떤 속성(변수)과 동작(메서드)을 가질지 정의하는 역할을 한다.

📝 예제 코드 (자동차 클래스)

class Car {
    String color;   // 속성 (변수)
    int speed;      // 속성 (변수)

    void drive() {  // 동작 (메서드)
        System.out.println("자동차가 달립니다!");
    }

    void stop() {   // 동작 (메서드)
        System.out.println("자동차가 멈춥니다!");
    }
}

✔ Car 클래스는 자동차의 속성(color, speed)과 동작(drive(), stop())을 정의

✔ 이제 Car 클래스를 기반으로 실제 자동차(객체)를 생성할 수 있음

---

2️⃣ 객체(Object)란? - 설계도로 만든 실체

객체는 클래스(설계도)를 기반으로 생성된 실체 이다.

즉, 클래스에서 정의한 속성과 동작을 실제로 수행할 수 있는 존재이다.

📝 객체 생성 및 사용 예제

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car();  // 객체 생성
        myCar.color = "빨강";  // 속성 설정
        myCar.speed = 100;

        myCar.drive();  // 자동차가 달립니다!
        System.out.println("색상: " + myCar.color);  // 색상: 빨강
    }
}

✔ Car myCar = new Car(); → Car 클래스 기반으로 myCar 객체 생성

✔ 객체의 속성을 설정하고(myCar.color = "빨강";) 동작을 실행 (myCar.drive();)

---

3️⃣ 생성자(Constructor) - 객체 초기화 담당

생성자는 객체가 생성될 때 자동으로 호출되는 특수한 메서드 이다.

주로 객체의 속성을 초기화하는 역할을 한다.

📝 생성자 사용 예제

class Car {
    String color;
    int speed;

    // 생성자 정의
    Car(String color, int speed) {
        this.color = color;
        this.speed = speed;
    }

    void drive() {
        System.out.println(color + " 자동차가 " + speed + "km/h로 달립니다!");
    }
}

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car("파란색", 120);  // 객체 생성 시 자동으로 초기화
        myCar.drive();  // 파란색 자동차가 120km/h로 달립니다!
    }
}

✔ Car(String color, int speed) → 생성자에서 속성을 초기화

✔ 객체를 생성할 때 값("파란색", 120)을 전달하여 자동 설정 가능

---

🎯 3단계 요약

개념	설명	예제
클래스(Class)	객체를 만들기 위한 설계도	class Car { String color; void drive() {} }
객체(Object)	클래스를 기반으로 생성된 실체	Car myCar = new Car();
생성자(Constructor)	객체 생성 시 자동 호출되는 초기화 메서드	Car(String color) { this.color = color; }

➡️ 클래스(설계도)를 기반으로 객체(실체)를 만들고, 생성자를 활용하면 더 편리한 초기화가 가능하다! 🚗

---

📌 4단계: 접근 제어자 & 메서드 오버로딩

1️⃣ 접근 제어자(Access Modifier) - 데이터 보호

접근 제어자는 클래스의 변수(필드)나 메서드에 접근할 수 있는 범위를 제한하는 키워드이다.

즉, 데이터를 보호하고, 불필요한 접근을 차단하는 역할을 한다.

---

🔹 접근 제어자의 종류

접근 제어자	같은 클래스	같은 패키지	상속 관계(다른 패키지)	다른 패키지
public	✅	✅	✅	✅
protected	✅	✅	✅	❌
default(아무것도 안 씀)	✅	✅	❌	❌
private	✅	❌	❌	❌

✔ public → 어디서든 접근 가능

✔ protected → 같은 패키지 또는 상속받은 클래스에서만 접근 가능

✔ default → 같은 패키지에서만 접근 가능 (아무것도 안 쓰면 기본값)

✔ private → 같은 클래스 내부에서만 접근 가능

---

🔹 예제: 접근 제어자 적용하기

class BankAccount {
    private int balance = 1000; // `private` -> 외부에서 직접 접근 불가

    // Getter 메서드 (읽기 가능)
    public int getBalance() {
        return balance;
    }

    // Setter 메서드 (쓰기 가능)
    public void deposit(int amount) {
        if (amount > 0) {
            balance += amount;
        }
    }
}

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount();

        // 직접 접근 불가 (오류 발생)
        // account.balance = 5000;

        account.deposit(500);  // 500원 입금
        System.out.println("잔액: " + account.getBalance());  // 잔액: 1500
    }
}

✔ private로 balance를 숨겨 외부에서 직접 수정 불가능

✔ public 메서드(deposit()과 getBalance())를 통해서만 접근 가능

---

2️⃣ 메서드 오버로딩(Method Overloading) - 같은 이름, 다른 매개변수

메서드 오버로딩은 같은 이름의 메서드를 매개변수(파라미터)를 다르게 하여 여러 개 정의하는 것을 의미한다.

즉, 같은 기능을 수행하지만, 입력값에 따라 다른 동작을 할 수 있도록 하는 기능이다.

---

🔹 메서드 오버로딩 예제

class MathUtil {
    // 정수 덧셈
    int add(int a, int b) {
        return a + b;
    }

    // 실수 덧셈 (오버로딩)
    double add(double a, double b) {
        return a + b;
    }

    // 세 개의 숫자를 더하는 메서드 (오버로딩)
    int add(int a, int b, int c) {
        return a + b + c;
    }
}

public class Main {
    public static void main(String[] args) {
        MathUtil calc = new MathUtil();

        System.out.println(calc.add(2, 3));      // 5
        System.out.println(calc.add(2.5, 3.2));  // 5.7
        System.out.println(calc.add(1, 2, 3));   // 6
    }
}

✔ add() 메서드를 다양한 매개변수로 정의하여 오버로딩 구현

✔ 정수, 실수, 3개의 숫자를 더할 때 같은 add() 메서드를 사용 가능

---

🎯 4단계 요약

개념	설명	예제
접근 제어자	클래스 멤버(변수, 메서드)에 대한 접근 범위를 제한	private int balance;
public	어디서든 접근 가능	public void deposit() {}
protected	같은 패키지 & 상속 관계에서 접근 가능	protected int age;
default	같은 패키지에서만 접근 가능	int score;
private	같은 클래스에서만 접근 가능	private String password;
메서드 오버로딩	같은 이름의 메서드를 매개변수에 따라 다르게 정의	int add(int a, int b) / double add(double a, double b)

➡️ 접근 제어자를 활용하면 데이터 보호가 가능하고, 메서드 오버로딩을 활용하면 코드의 유연성이 증가한다! 🚀

---

📌 5단계: 상속(Inheritance)과 메서드 오버라이딩(Overriding)

상속과 오버라이딩은 객체지향 프로그래밍(OOP)의 강력한 기능으로, 코드 재사용성과 유연성을 극대화하는 데 도움을 준다.

---

1️⃣ 상속(Inheritance) - 부모 클래스를 확장하여 재사용

상속은 기존 클래스(부모)의 기능을 물려받아 새로운 클래스(자식)를 만드는 것을 의미한다.

즉, 공통된 기능을 부모 클래스에 정의하고, 이를 자식 클래스가 재사용하는 방식이다.

---

🔹 상속의 장점

✅ 코드 재사용 가능 → 중복 코드 최소화

✅ 유지보수 용이 → 부모 클래스 수정 시, 자식 클래스에도 자동 반영

✅ 기능 확장 가능 → 부모의 기능을 기반으로 새로운 기능 추가 가능

---

🔹 예제: 동물 클래스를 상속한 개와 고양이

class Animal {  // 부모 클래스
    void eat() {
        System.out.println("먹는다!");
    }
}

// 🐕 개 클래스 (Animal을 상속받음)
class Dog extends Animal {
    void bark() {
        System.out.println("멍멍!");
    }
}

// 🐱 고양이 클래스 (Animal을 상속받음)
class Cat extends Animal {
    void meow() {
        System.out.println("야옹!");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.eat();  // 부모 클래스 기능 사용 ("먹는다!")
        myDog.bark(); // 개 클래스 기능 사용 ("멍멍!")

        Cat myCat = new Cat();
        myCat.eat();  // 부모 클래스 기능 사용 ("먹는다!")
        myCat.meow(); // 고양이 클래스 기능 사용 ("야옹!")
    }
}

✔ Dog와 Cat은 Animal의 eat() 메서드를 상속받아 사용 가능

✔ 각 클래스에서 추가적인 기능(bark(), meow())을 정의

---

2️⃣ 메서드 오버라이딩(Method Overriding) - 부모 메서드 재정의

메서드 오버라이딩은 부모 클래스의 메서드를 자식 클래스에서 재정의(변경)하는 것을 의미한다.

즉, 부모 클래스에서 제공한 기본 동작을 자식 클래스에서 변경할 수 있도록 하는 기능이다.

---

🔹 메서드 오버라이딩의 규칙

✔ 메서드 이름, 반환 타입, 매개변수가 동일해야 함

✔ 접근 제어자는 부모 메서드보다 더 좁은 범위로 설정할 수 없음

✔ 부모 메서드보다 더 넓은 기능을 제공해야 함

---

🔹 예제: 동물 소리 재정의하기 (오버라이딩 적용)

class Animal {
    void speak() {
        System.out.println("동물이 소리를 낸다!");
    }
}

// 🐕 개 클래스 (Animal을 상속받음)
class Dog extends Animal {
    @Override  // 부모의 speak() 메서드를 오버라이딩
    void speak() {
        System.out.println("멍멍!");
    }
}

// 🐱 고양이 클래스 (Animal을 상속받음)
class Cat extends Animal {
    @Override
    void speak() {
        System.out.println("야옹!");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal myPet = new Dog();
        myPet.speak();  // "멍멍!" (오버라이딩된 메서드 실행)

        myPet = new Cat();
        myPet.speak();  // "야옹!" (오버라이딩된 메서드 실행)
    }
}

✔ 부모 클래스 Animal의 speak() 메서드를 Dog와 Cat에서 각각 다르게 구현 (오버라이딩)

✔ 같은 Animal 타입이지만 speak() 실행 시 결과가 다르게 출력됨 (다형성 활용)

---

3️⃣ super 키워드 - 부모 클래스의 메서드 호출

오버라이딩한 메서드에서 부모 클래스의 원래 기능을 사용하고 싶을 때 super 키워드를 사용한다.

---

🔹 예제: super 키워드 사용하기

class Animal {
    void speak() {
        System.out.println("동물이 소리를 낸다!");
    }
}

class Dog extends Animal {
    @Override
    void speak() {
        super.speak();  // 부모 클래스의 speak() 실행
        System.out.println("멍멍!");  // 추가 기능
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.speak();
    }
}

출력 결과:

동물이 소리를 낸다!
멍멍!

✔ super.speak();을 사용해 부모 클래스의 speak()를 먼저 실행한 후, 추가 기능 수행

---

4️⃣ 다중 상속 문제 - Java에서 인터페이스 활용

자바에서는 다중 상속(여러 부모 클래스를 동시에 상속)을 허용하지 않는다.

이유:

✅ 두 부모 클래스에 같은 이름의 메서드가 있으면 충돌 가능

✅ 코드가 복잡해지고 유지보수가 어려움

하지만 인터페이스(interface) 를 활용하면 다중 상속과 유사한 효과를 낼 수 있다.

(인터페이스는 다음 단계에서 자세히 설명!)

---

🎯 5단계 요약

개념	설명	예제
상속(Inheritance)	부모 클래스의 기능을 물려받아 코드 재사용	class Dog extends Animal {}
오버라이딩(Overriding)	부모 클래스의 메서드를 자식 클래스에서 재정의	@Override void speak() {}
super 키워드	부모 클래스의 메서드를 호출할 때 사용	super.speak();
다중 상속 문제	자바에서는 다중 상속을 지원하지 않음	인터페이스로 해결 가능

➡️ 상속을 활용하면 코드 재사용이 가능하고, 오버라이딩을 통해 유연한 코드 확장이 가능하다! 🚀

---

📌 6단계: 인터페이스(Interface)와 추상 클래스(Abstract Class)

자바에서는 다중 상속을 지원하지 않지만, 인터페이스(Interface)와 추상 클래스(Abstract Class) 를 활용하면 유연한 설계가 가능하다.

이 두 개념은 객체지향 설계 원칙(SOLID) 중 개방-폐쇄 원칙(Open-Closed Principle)을 따르며, 유지보수성과 확장성을 높이는 핵심 요소이다.

---

1️⃣ 추상 클래스(Abstract Class) - “공통적인 특징을 정의”

추상 클래스는 일반 클래스와 인터페이스의 중간 형태로, 일부는 구현하고 일부는 구현하지 않는 클래스이다.

즉, 추상 클래스 자체로는 객체를 만들 수 없고, 상속받은 자식 클래스가 구현해야 하는 필수 메서드를 정의할 수 있다.

---

🔹 추상 클래스의 특징

✔ abstract 키워드를 사용해 선언

✔ 일부 메서드는 구현 가능, 일부는 강제적으로 구현하도록 설정 가능 (abstract 메서드)

✔ 객체를 직접 생성할 수 없음 (new 사용 불가)

✔ 자식 클래스는 반드시 abstract 메서드를 구현해야 함

---

🔹 예제: 자동차(Car) 추상 클래스

// 🚗 추상 클래스 정의
abstract class Car {
    abstract void drive();  // 추상 메서드 (구현 필요)

    public void stop() {  // 일반 메서드 (그대로 사용 가능)
        System.out.println("자동차가 멈춥니다.");
    }
}

// 🏎️ 스포츠카 (추상 클래스 상속)
class SportsCar extends Car {
    @Override
    void drive() {
        System.out.println("스포츠카가 빠르게 달립니다!");
    }
}

// 🚚 트럭 (추상 클래스 상속)
class Truck extends Car {
    @Override
    void drive() {
        System.out.println("트럭이 무겁게 이동합니다.");
    }
}

public class Main {
    public static void main(String[] args) {
        Car myCar = new SportsCar();
        myCar.drive();  // "스포츠카가 빠르게 달립니다!"
        myCar.stop();   // "자동차가 멈춥니다."
    }
}

✔ Car는 추상 클래스이므로 직접 객체를 생성할 수 없음 (new Car(); 불가)

✔ 자식 클래스에서 drive()를 반드시 구현해야 함

✔ 공통 동작(stop())은 그대로 사용 가능

---

2️⃣ 인터페이스(Interface) - “다중 상속을 지원하는 강제 설계”

인터페이스는 클래스가 반드시 구현해야 하는 메서드를 정의하는 틀이다.

즉, 인터페이스는 설계도 역할을 하며, 다중 구현이 가능하여 유연한 구조를 만들 수 있다.

---

🔹 인터페이스의 특징

✔ interface 키워드를 사용해 선언

✔ 모든 메서드는 기본적으로 public abstract (구현 X, 선언만 가능)

✔ 필드(변수)는 public static final (상수로만 선언 가능)

✔ 다중 구현(다중 상속)이 가능

---

🔹 예제: 동물(Animal) 인터페이스

// 🐾 인터페이스 정의
interface Animal {
    void makeSound();  // 추상 메서드 (반드시 구현 필요)
}

// 🐶 강아지 클래스 (Animal 인터페이스 구현)
class Dog implements Animal {
    @Override
    public void makeSound() {
        System.out.println("멍멍!");
    }
}

// 🐱 고양이 클래스 (Animal 인터페이스 구현)
class Cat implements Animal {
    @Override
    public void makeSound() {
        System.out.println("야옹!");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal myDog = new Dog();
        Animal myCat = new Cat();

        myDog.makeSound();  // "멍멍!"
        myCat.makeSound();  // "야옹!"
    }
}

✔ 인터페이스 Animal을 Dog와 Cat이 구현 (implements 사용)

✔ 인터페이스에 정의된 메서드는 반드시 구현해야 함 (makeSound())

✔ 인터페이스를 사용하면 다형성을 극대화할 수 있음

---

3️⃣ 추상 클래스 vs 인터페이스 - 언제 사용할까?

특징	추상 클래스	인터페이스
상속 방식	단일 상속 (extends)	다중 구현 가능 (implements)
메서드 구현	구현된 메서드 포함 가능	모든 메서드는 구현 불가 (기본적으로 abstract)
변수 선언	일반 변수 사용 가능	public static final (상수)만 사용 가능
객체 생성	직접 생성 불가	직접 생성 불가
사용 목적	공통 기능 제공 + 일부 강제	설계만 제공, 모든 구현 강제

✔ 공통된 기능(일부 구현된 메서드 포함)도 제공해야 한다면? → 추상 클래스 사용

✔ 완전히 독립적인 설계를 강제하고, 다중 구현이 필요하다면? → 인터페이스 사용

---

4️⃣ 인터페이스의 다중 구현 - Java의 다중 상속 대체

자바는 다중 상속을 지원하지 않지만, 인터페이스를 통해 다중 구현이 가능하다.

---

🔹 예제: 다중 인터페이스 구현하기

// 🛠️ 첫 번째 인터페이스 (운전 가능)
interface Drivable {
    void drive();
}

// 🎶 두 번째 인터페이스 (음악 재생 가능)
interface MusicPlayable {
    void playMusic();
}

// 🚗 자동차 클래스 (두 개의 인터페이스 구현)
class SmartCar implements Drivable, MusicPlayable {
    @Override
    public void drive() {
        System.out.println("스마트카가 자율 주행합니다.");
    }

    @Override
    public void playMusic() {
        System.out.println("음악을 재생합니다.");
    }
}

public class Main {
    public static void main(String[] args) {
        SmartCar myCar = new SmartCar();
        myCar.drive();     // "스마트카가 자율 주행합니다."
        myCar.playMusic(); // "음악을 재생합니다."
    }
}

✔ SmartCar 클래스는 Drivable과 MusicPlayable을 동시에 구현

✔ 인터페이스를 사용하면 다중 상속과 유사한 효과를 낼 수 있음

---

🎯 6단계 요약

개념	설명	예제
추상 클래스	일부 메서드를 구현하고, 일부는 강제	abstract class Car { abstract void drive(); }
인터페이스	모든 메서드를 강제하며, 다중 구현 가능	interface Animal { void makeSound(); }
추상 클래스 사용 시기	공통 기능 제공 + 일부 강제	abstract class Car { void stop() {} }
인터페이스 사용 시기	다중 구현 가능 + 강제성 필요	class Dog implements Animal {}
다중 구현	여러 인터페이스를 동시에 구현 가능	class SmartCar implements Drivable, MusicPlayable {}

➡️ 추상 클래스는 공통 기능을 제공하면서 일부 메서드를 강제해야 할 때, 인터페이스는 다중 구현이 필요하고 모든 기능을 강제해야 할 때 사용한다! 🚀

---

📌 7단계: 객체지향 설계 원칙(SOLID)와 응용

객체지향 프로그래밍(OOP)을 효과적으로 활용하려면 좋은 설계 원칙을 따라야 한다.

대표적인 객체지향 설계 원칙이 바로 SOLID 원칙이다.

SOLID 원칙을 따르면 유지보수성, 확장성, 가독성이 뛰어난 코드를 작성할 수 있다. 🚀

---

1️⃣ SOLID 원칙이란?

SOLID는 다섯 가지 객체지향 설계 원칙의 앞 글자를 딴 것이다.

이 원칙들은 코드를 변경하기 쉽게 하고, 재사용성을 높이는 데 도움을 준다.

원칙	설명
S - 단일 책임 원칙 (Single Responsibility Principle)	하나의 클래스는 하나의 책임만 가져야 한다.
O - 개방-폐쇄 원칙 (Open-Closed Principle)	기존 코드를 변경하지 않고 확장할 수 있어야 한다.
L - 리스코프 치환 원칙 (Liskov Substitution Principle)	자식 클래스는 부모 클래스를 대체할 수 있어야 한다.
I - 인터페이스 분리 원칙 (Interface Segregation Principle)	하나의 거대한 인터페이스보다는 여러 개의 작은 인터페이스를 사용해야 한다.
D - 의존 역전 원칙 (Dependency Inversion Principle)	상위(추상) 모듈이 하위(구체) 모듈에 의존하면 안 된다.

---

2️⃣ SOLID 원칙을 코드로 이해하기

🔹 (S) 단일 책임 원칙 (Single Responsibility Principle, SRP)

✔ 한 클래스는 하나의 책임만 가져야 한다.

✔ 하나의 이유로만 변경되어야 한다.

❌ 위반 예제 (하나의 클래스가 너무 많은 일을 함)

class OrderManager {
    void processOrder() {
        System.out.println("주문을 처리합니다.");
    }

    void printInvoice() {
        System.out.println("영수증을 출력합니다.");
    }

    void sendEmailNotification() {
        System.out.println("이메일을 발송합니다.");
    }
}

✔ OrderManager 클래스가 주문 처리, 영수증 출력, 이메일 전송까지 모든 기능을 담당

✔ 책임이 많아지면 유지보수가 어려워짐

---

✅ 올바른 예제 (책임을 분리)

class OrderProcessor {
    void processOrder() {
        System.out.println("주문을 처리합니다.");
    }
}

class InvoicePrinter {
    void printInvoice() {
        System.out.println("영수증을 출력합니다.");
    }
}

class EmailNotifier {
    void sendEmailNotification() {
        System.out.println("이메일을 발송합니다.");
    }
}

✔ OrderProcessor, InvoicePrinter, EmailNotifier 클래스를 각각 만들어 책임을 분리

✔ 유지보수와 확장성이 향상됨

---

🔹 (O) 개방-폐쇄 원칙 (Open-Closed Principle, OCP)

✔ 코드를 수정하지 않고 기능을 확장할 수 있어야 한다.

✔ 새로운 기능이 추가될 때 기존 코드를 변경하지 않고 확장할 수 있도록 설계해야 한다.

❌ 위반 예제 (기존 코드를 수정해야 하는 경우)

class PaymentProcessor {
    void processPayment(String paymentType) {
        if (paymentType.equals("CreditCard")) {
            System.out.println("신용카드 결제 처리");
        } else if (paymentType.equals("PayPal")) {
            System.out.println("PayPal 결제 처리");
        }
    }
}

✔ processPayment()에 새로운 결제 수단을 추가할 때마다 코드를 수정해야 함

---

✅ 올바른 예제 (새로운 결제 방식 추가 가능)

interface PaymentMethod {
    void processPayment();
}

class CreditCardPayment implements PaymentMethod {
    public void processPayment() {
        System.out.println("신용카드 결제 처리");
    }
}

class PayPalPayment implements PaymentMethod {
    public void processPayment() {
        System.out.println("PayPal 결제 처리");
    }
}

class PaymentProcessor {
    void processPayment(PaymentMethod paymentMethod) {
        paymentMethod.processPayment();
    }
}

✔ 새로운 결제 방식을 추가할 때 PaymentProcessor 코드를 수정할 필요 없음

✔ 확장에는 열려 있고(Open), 수정에는 닫혀 있음(Closed)

---

🔹 (L) 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

✔ 자식 클래스는 부모 클래스를 대체할 수 있어야 한다.

✔ 상속이 올바르게 사용되었는지 검증하는 원칙이다.

❌ 위반 예제 (부모 클래스 기능을 제한하는 자식 클래스)

class Bird {
    void fly() {
        System.out.println("새가 날아갑니다.");
    }
}

class Penguin extends Bird {
    @Override
    void fly() {
        throw new UnsupportedOperationException("펭귄은 날 수 없습니다.");
    }
}

✔ Penguin 클래스가 Bird 클래스를 상속했지만, fly()를 사용할 수 없음 → 잘못된 설계

---

✅ 올바른 예제 (부모 클래스를 대체할 수 있도록 수정)

abstract class Bird {
    abstract void move();
}

class Sparrow extends Bird {
    @Override
    void move() {
        System.out.println("참새가 날아갑니다.");
    }
}

class Penguin extends Bird {
    @Override
    void move() {
        System.out.println("펭귄이 헤엄칩니다.");
    }
}

✔ move()라는 일반적인 메서드를 사용하여 Penguin과 Sparrow를 동일한 방식으로 처리 가능

---

🔹 (I) 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

✔ 하나의 큰 인터페이스보다는 여러 개의 작은 인터페이스를 만들어 필요한 기능만 구현할 수 있도록 해야 한다.

❌ 위반 예제 (불필요한 메서드 구현 강요)

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {
    @Override
    public void work() {
        System.out.println("로봇이 일을 합니다.");
    }

    @Override
    public void eat() {
        throw new UnsupportedOperationException("로봇은 밥을 먹지 않습니다.");
    }
}

✔ Robot 클래스는 eat()을 구현할 필요가 없음

---

✅ 올바른 예제 (인터페이스 분리 적용)

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class Human implements Workable, Eatable {
    public void work() {
        System.out.println("사람이 일을 합니다.");
    }

    public void eat() {
        System.out.println("사람이 밥을 먹습니다.");
    }
}

class Robot implements Workable {
    public void work() {
        System.out.println("로봇이 일을 합니다.");
    }
}

✔ 인터페이스를 분리하여, 필요한 기능만 구현하도록 함

---

🔹 (D) 의존 역전 원칙 (Dependency Inversion Principle, DIP)

✔ 구체적인 클래스가 아닌, 추상적인 인터페이스에 의존해야 한다.

✔ “상위(추상) 모듈이 하위(구체) 모듈에 의존하면 안 된다.”

interface MessageSender {
    void sendMessage(String message);
}

class EmailSender implements MessageSender {
    public void sendMessage(String message) {
        System.out.println("이메일 전송: " + message);
    }
}

class NotificationService {
    private MessageSender sender;

    NotificationService(MessageSender sender) {
        this.sender = sender;
    }

    void notifyUser(String message) {
        sender.sendMessage(message);
    }
}

✔ NotificationService는 EmailSender가 아니라 MessageSender 인터페이스에 의존

✔ 다른 메시지 전송 방식(SMS, 카카오톡 등) 추가 가능

---

🎯 7단계 요약: SOLID 원칙 적용하면 좋은 점

✅ 유지보수성이 뛰어난 코드

✅ 확장하기 쉬운 구조

✅ 버그 발생 확률 감소

➡️ SOLID 원칙을 따르면 객체지향 프로그래밍이 더욱 강력해진다! 🚀