TIL - 2025.03.01

[Yumi-Park996]

접근제어자 복습

1. private: 해당 클래스 내부에서만 접근 가능

의미

• 해당 클래스 안에서만 접근 가능
• 같은 패키지에 있든, 상속을 받았든, 다른 클래스에서는 절대 접근 불가
• 완벽한 정보 은닉(Encapsulation)을 위한 제어자
  예제 코드

class Person {
   private String name = "John";  // private 필드 (Person 클래스 내부에서만 접근 가능)

   public String getName() {   // 외부에 공개하는 메서드
       return name;
   }

   private void secretMethod() {  // private 메서드 (Person 클래스 안에서만 호출 가능)
       System.out.println("비밀 메서드 실행");
   }

   public void callSecretMethod() {
       secretMethod();  // 클래스 내부에서는 private 메서드 호출 가능
   }
}

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

       // System.out.println(p.name); // 컴파일 에러 (private 필드는 외부에서 직접 접근 불가)
       System.out.println(p.getName()); // public 메서드를 통해 우회 접근 가능

       // p.secretMethod(); // 컴파일 에러 (private 메서드 호출 불가)
       p.callSecretMethod(); // 우회 메서드를 통해 호출 가능
   }
}

포인트

• 정보 은닉 완벽 보장
• 외부에서 직접 접근을 차단하고, 반드시 공개된 메서드(public)를 통해서만 접근하도록 유도
• 안전한 캡슐화 설계에 필수

---

2. default: 같은 패키지 내에서만 접근 가능 (접근 제어자 생략 시)

의미

• 아무 접근 제어자도 안 쓰면 default
• 같은 패키지 안에서는 접근 가능
• 다른 패키지에서는 접근 불가
• 패키지 단위 모듈화를 위한 제어자
  예제 코드

// mypackage/Person.java
package mypackage;

class Person {  // 접근 제어자 생략 = default
    String name = "John";  // default 필드

    void sayHello() {  // default 메서드
        System.out.println("Hello, " + name);
    }
}

// mypackage/Main.java
package mypackage;

public class Main {
    public static void main(String[] args) {
        Person p = new Person();  // 같은 패키지이므로 접근 가능
        System.out.println(p.name);  // 같은 패키지라 접근 가능
        p.sayHello();  // 같은 패키지라 접근 가능
    }
}

다른 패키지에서 접근 시

// 다른 패키지에서는 아래처럼 오류 발생
/*
// 다른패키지/OtherPackageClass.java
package 다른패키지;

import mypackage.Person;  // ❌ 에러! 같은 패키지가 아니라서 import 자체가 불가

public class OtherPackageClass {
    public static void main(String[] args) {
        Person p = new Person();  // ❌ 접근 불가
    }
}
*/

포인트

• 같은 패키지 내에서만 접근 가능
• 패키지 단위로 기능을 묶어서 외부 접근을 제한할 때 유용
• 외부 노출 최소화의 기본 전략으로 사용 가능

---

3. protected: 같은 패키지 또는 하위 클래스에서 접근 가능

의미

• 같은 패키지에서는 default처럼 접근 가능
• 다른 패키지라도 상속받은 자식 클래스라면 접근 가능
• 부모가 자식에게 상속해주고 싶은 중요한 데이터나 메서드에 주로 사용
  예제 코드
  부모 클래스 (parentpkg/Parent.java)

package parentpkg;

public class Parent {
    protected String name = "John";  // protected 필드

    protected void sayHello() {  // protected 메서드
        System.out.println("Hello, " + name);
    }
}

같은 패키지 자식 클래스 (parentpkg/SamePackageChild.java)

package parentpkg;

public class SamePackageChild extends Parent {
    public void greet() {
        System.out.println(name);  // 같은 패키지라 바로 접근 가능
        sayHello();  // 같은 패키지라 바로 호출 가능
    }
}

다른 패키지 자식 클래스 (childpkg/Child.java)

package childpkg;

import parentpkg.Parent;

public class Child extends Parent {
    public void greet() {
        System.out.println(name);  // 다른 패키지지만 상속받아서 접근 가능
        sayHello();  // 다른 패키지지만 상속받아서 호출 가능
    }
}

다른 패키지에서의 사용 (childpkg/Main.java)

package childpkg;

public class Main {
    public static void main(String[] args) {
        Child c = new Child();
        c.greet();  // 상속받은 메서드를 통해 protected 접근 가능

        // c.name;  // 컴파일 에러 (protected는 자식 클래스 내부에서만 접근 가능)
    }
}

포인트

• protected는 상속 구조에서 자식 클래스에 필요한 정보만 전달할 때 사용
• 외부 클래스는 접근 불가
• 실무에서는 상속 구조를 최소화하려는 트렌드 때문에 많이 쓰이진 않음
• 프레임워크에서는 확장 포인트로 제공하는 경우 많음

---

4. public: 어디서나 접근 가능

의미

• 패키지와 상관없이 어디서든 접근 가능
• 완전한 공개
• 외부 API, 라이브러리 인터페이스 등에 주로 사용
  예제 코드
  mypackage/Person.java

package mypackage;

public class Person {
    public String name = "John";  // public 필드

    public void sayHello() {  // public 메서드
        System.out.println("Hello, " + name);
    }
}

다른 패키지에서 접근 (otherpackage/Main.java)

package otherpackage;

import mypackage.Person;

public class Main {
    public static void main(String[] args) {
        Person p = new Person();
        System.out.println(p.name);  // 다른 패키지에서도 접근 가능
        p.sayHello();  // 다른 패키지에서도 호출 가능
    }
}

포인트

• 공개 API 설계할 때 기본으로 사용
• 과도한 공개는 캡슐화 위반
• 실무에서는 꼭 필요한 메서드만 공개하고, 나머지는 숨기는 방식으로 설계

[Yumi-Park996]

생성자

생성자란?

• 클래스와 이름이 같고, 반환형이 없는 특수한 메서드.
• 객체가 생성될 때 자동으로 한 번만 호출.
• 주 역할: 객체가 가져야 할 초기 상태를 세팅.
  생성자가 왜 필요할까?
• 생성자가 없다면?
• 객체를 만들고, 매번 직접 필드를 일일이 초기화해야 함.
• 누락되는 경우도 생김.
• 객체가 완전한 상태로 만들어지지 않을 위험이 있음.

class Person {
    String name;
    int age;
}

public class Main {
    public static void main(String[] args) {
        Person p = new Person();
        p.name = "John";  // 매번 이런 초기화가 필요
        p.age = 30;
    }
}

class Person {
    String name;
    int age;

    // 생성자
    Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

public class Main {
    public static void main(String[] args) {
        Person p = new Person("John", 30);  // 한 번에 초기화
    }
}

생성자의 종류와 예제

1) 기본 생성자 (No-Arg Constructor)
설명

• 매개변수가 없는 생성자.
• 아무 값도 받지 않고, 기본값을 설정.
  예제

class Sample {
    int number;

    // 기본 생성자
    Sample() {
        number = 10;  // 기본값 설정
        System.out.println("기본 생성자 실행됨 - number: " + number);
    }

    public static void main(String[] args) {
        Sample s = new Sample();  // 기본 생성자 호출
        System.out.println("생성된 객체의 number 값: " + s.number);
    }
}

출력 예시

기본 생성자 실행됨 - number: 10
생성된 객체의 number 값: 10

2) 매개변수 생성자 (Parameterized Constructor)
설명
필요한 값을 매개변수로 받아서 바로 초기화.
객체마다 다른 초기값을 가질 수 있음.
예제

class Sample {
    String message;

    Sample(String msg) {
        message = msg;
        System.out.println("매개변수 생성자 실행됨 - message: " + message);
    }

    public static void main(String[] args) {
        Sample first = new Sample("Hello");   // 매개변수 생성자 호출
        Sample second = new Sample("World");   // 매개변수 생성자 호출
    }
}
출력 예시
```yaml
매개변수 생성자 실행됨 - message: Hello
매개변수 생성자 실행됨 - message: World

3) 생성자 오버로딩 (Constructor Overloading)
설명
같은 이름의 생성자를 매개변수의 개수나 타입을 다르게 해서 여러 개 정의하는 것.
상황에 따라 다양한 초기화 방법을 제공할 수 있음.
예제

class Sample {
    String info;

    // 기본 생성자
    Sample() {
        info = "Default";
        System.out.println("기본 생성자 실행됨 - info: " + info);
    }

    // 매개변수 있는 생성자
    Sample(String info) {
        this.info = info;
        System.out.println("매개변수 생성자 실행됨 - info: " + info);
    }

    void printInfo() {
        System.out.println("현재 info 값: " + info);
    }

    public static void main(String[] args) {
        Sample one = new Sample();               // 기본 생성자 호출
        Sample two = new Sample("Custom");        // 매개변수 생성자 호출

        one.printInfo();
        two.printInfo();
    }
}

출력 예시

기본 생성자 실행됨 - info: Default
매개변수 생성자 실행됨 - info: Custom
현재 info 값: Default
현재 info 값: Custom

[Yumi-Park996]

아주 좋은 질문이에요!
"상속받았으면 부모 메서드 그냥 쓰면 되는데, 왜 super를 굳이 써야 하는가?"
이 부분 헷갈릴 수 있는데, 핵심은 **"상황에 따라 super가 필요한 경우"**가 있기 때문이에요.

📌 핵심 요점

• 그냥 상속받은 부모 메서드 호출: 자식 클래스에서 아무 것도 안 덮어쓰면, 당연히 부모 메서드 그냥 쓸 수 있음 (super 필요 없음)
• 오버라이딩한 경우: 자식 메서드 안에서 "부모 버전도 함께 실행하고 싶을 때" super를 써야 함

---

📚 super를 굳이 써야 하는 상황 3가지

---

1️⃣ 부모 메서드도 실행하고 싶을 때 (오버라이딩한 경우)

예시

class Vehicle {
    public void move() {
        System.out.println("Vehicle moves.");
    }
}
class Car extends Vehicle {

@Override

public void move() {

super.move();  // 부모의 move() 호출

System.out.println("Car moves faster.");

}

}

설명

• 부모의 move()도 실행하고
• 자식의 move()도 실행하고 싶은 경우
• 이때 super 없으면 부모 메서드 안 불러짐 → super가 필요!

---

2️⃣ 부모 클래스에 생성자가 있을 때

예시

class Employee {
    Employee(String name) {
        System.out.println("Employee 생성자 호출: " + name);
    }
}
class Manager extends Employee {

Manager(String name) {

super(name);  // 부모 생성자 호출 (이거 없으면 컴파일 에러)

System.out.println("Manager 생성자 호출");

}

}

설명

• 부모 클래스가 기본 생성자 없이 매개변수 생성자만 있으면
• 자식 생성자에서 super()로 반드시 부모 생성자 호출해야 함
• 안 하면 컴파일 에러 발생
• 이건 Java 문법이 강제하는 부분이라 "굳이"가 아니라 "무조건" 써야 함

---

3️⃣ 부모 클래스에서 private 메서드와 필드는 직접 접근 불가

예시

class Parent {
    private String secret = "비밀";
public String getSecret() {
    return secret;
}

}
class Child extends Parent {

public void printSecret() {

System.out.println(super.getSecret());  // 부모 메서드를 통해 private 필드 접근

}

}

설명

• 부모의 private 필드는 자식이 직접 접근 불가
• 부모 메서드(public getSecret())를 super로 호출해 접근 가능
• 이런 식으로 캡슐화를 유지하면서 접근할 때 super가 유용

---

🚨 오버라이딩 안 하면 super 필요 없음

예시

class Parent {
    public void sayHello() {
        System.out.println("Hello from Parent");
    }
}
class Child extends Parent {

// 오버라이딩 안 함

}
public class Main {

public static void main(String[] args) {

Child c = new Child();

c.sayHello();  // 그냥 부모 메서드 호출, super 필요 없음

}

}

• 부모 메서드 그대로 쓰는 경우는 super 전혀 필요 없음

---

✍️ 정리

상황	super 필요 여부
부모 메서드 그대로 사용	❌ 필요 없음
자식에서 오버라이딩하고 부모 메서드도 같이 호출하고 싶을 때	✅ 필요
부모 클래스에 매개변수 생성자가 있고 자식에서 부모 생성자 호출해야 할 때	✅ 필요
부모의 private 필드/메서드를 public 메서드 통해 우회 접근할 때	✅ 필요

---

💬 비유

• 부모 메서드 "그대로" 쓸 땐 부모집 냉장고에 있는 반찬 꺼내 먹는 거라 super 필요 없음
• 근데 자식이 반찬에 양념 더하고 싶으면 부모 반찬(super) + 자식 양념(오버라이드)을 섞어야 함
• 그때 super로 "부모 반찬"을 먼저 꺼내는 과정이 필요한 거!

---

✅ 한 줄 결론

부모 메서드 그대로 쓰면 super 필요 없음.
오버라이딩하거나 부모 생성자 강제 호출해야 할 땐 super 필수!

궁금한 거 더 있으면 편하게 물어봐! 👀

[Yumi-Park996]

아주 좋아요! "비유"로 설명해달라는 거 완전 환영이에요.
클래스랑 인터페이스의 차이를 진짜 쉽게, 비유 중심으로 풀어드릴게요.
(그리고 약속대로 "다형성"은 뺄게요. 지금은 몰라도 괜찮아요!)

---

🔧 클래스와 인터페이스 비유 (햄버거 가게 버전 🍔)

1️⃣ 클래스 = 레시피 + 요리법까지 다 적힌 메뉴판

햄버거 가게에서 '불고기버거' 레시피가 있다고 생각해봐요. 불고기버거 클래스는 이렇게 생겼을 거예요:

• 재료: 빵, 패티, 소스, 야채
• 만드는 방법: 패티 굽기 → 소스 바르기 → 야채 넣기 → 완성

➡️ 클래스는 **재료(속성) + 만드는 방법(메서드)**까지 전부 적힌 완성된 레시피라고 보면 돼요.

예시 코드

class BulgogiBurger {
    String bread = "참깨빵";
    String patty = "불고기 패티";
void makeBurger() {
    System.out.println("패티 굽고, 소스 바르고, 야채 넣고 완성!");
}

}

➡️ "불고기버거 클래스"는 실제로 불고기버거를 만드는 방법까지 다 들어있죠.

---

2️⃣ 인터페이스 = 가게에서 정해놓은 "메뉴 규칙표"

햄버거 가게 본사에서 각 가맹점에 "우리 가게 버거는 꼭 이런 기능이 있어야 해!"라고 규칙을 정해줬다고 생각해봐요.

• 모든 버거는 "버거 만들기" 기능이 있어야 한다.
• 모든 버거는 "가격 표시하기" 기능이 있어야 한다.

➡️ 인터페이스는 "이 기능 꼭 만들어라!"라는 규칙만 적어놓은 종이예요.
➡️ 어떻게 만들지는 가맹점(각 클래스)이 알아서 해요.

예시 코드

interface Burger {
    void makeBurger();    // 모든 버거는 꼭 만들어지는 기능이 있어야 함
    void showPrice();     // 모든 버거는 가격 보여주는 기능도 있어야 함
}

➡️ 인터페이스에는 무조건 필요한 기능 이름만 적혀있고, 내용(어떻게 만들지는)은 없음.

---

3️⃣ 클래스는 인터페이스 규칙을 따라가면서, 자기 방식대로 만든다

예를 들어, 불고기버거랑 치즈버거는 만드는 방식도 다르고, 가격도 다르지만,
어쨌든 "버거 만들기"랑 "가격 보여주기"는 꼭 있어야 한다는 본사 규칙을 따르는 거예요.

➡️ 이게 바로 **인터페이스 구현(implements)**이에요.

예시 코드

class BulgogiBurger implements Burger {
    @Override
    public void makeBurger() {
        System.out.println("불고기 패티 굽고 소스 뿌리기!");
    }
@Override
public void showPrice() {
    System.out.println("가격: 5,000원");
}

}
class CheeseBurger implements Burger {

@Override

public void makeBurger() {

System.out.println("치즈 올리고 패티 굽기!");

}
@Override
public void showPrice() {
    System.out.println("가격: 6,000원");
}

}

---

📌 차이점 정리

	클래스	인터페이스
역할	실제로 만드는 방법까지 다 적힘	이런 기능 꼭 만들어야 한다는 규칙만 적힘
내용	속성(재료) + 메서드(요리법) 다 있음	메서드 이름만 있고, 내용 없음
예시	"불고기버거 레시피"	"모든 버거는 만드는 기능과 가격표시 기능 꼭 있어야 함" 규칙
사용법	클래스는 그냥 바로 만들면 됨	인터페이스는 "반드시 구현"해서 써야 함

---

✨ 왜 인터페이스를 써야 할까?

햄버거 가게가 전국에 100개 있다고 해봐요.
본사에서 "버거 만드는 기능, 가격 보여주는 기능은 꼭 만들어야 해!"라고 정해주면,
각 가게는 자기 방식대로 버거를 만들 수 있어요.

• 서울점: 불고기버거, 새우버거
• 부산점: 치즈버거, 베이컨버거

하지만 공통점은 **"모두 다 같은 규칙"**을 따른다는 거예요.
➡️ 이게 인터페이스를 쓰는 진짜 이유예요.

---

💬 한 줄 정리

• 클래스: "레시피 + 요리법"까지 다 들어있는 실제 설계도
• 인터페이스: "이 기능은 꼭 있어야 해!"라는 본사의 규칙표

---

🚨 지금은 이렇게만 이해하고 넘어가도 돼요

인터페이스는 "규칙 정해주는 역할"
클래스는 "실제로 동작하는 완성품"
클래스만 알아도 대부분 프로그램 짤 수 있음
인터페이스는 "여러 규칙을 한 번에 지키게 할 때" 나중에 더 유용해져요.

---

🧩 이해됐는지 확인 질문

1. 불고기버거 클래스에는 패티 굽는 방법까지 적혀있어요.
2. 근데 인터페이스에는 왜 '이름만' 적어놓을까요?
   👉 한번 생각해보고 답해봐요!
   (답할 때 어려우면 힌트 줄게요 😎)

---

궁금한 거 더 있으면 편하게 물어봐요!
지금 단계에서는 쉽게, 핵심만 잡는 게 제일 중요해요 💪