[Java] 객체지향 프로그래밍(OOP) - 1. 개요

---

1) 고급 객체 지향 프로그래밍(OOP)란? 🧱

• 객체(Object): 데이터(필드) + 행동(메서드)을 묶은 단위
• 캡슐화, 상속, 다형성, 추상화가 기본 4요소
• “고급” OOP는 다음을 더 신경 씁니다 :

---

 ① 인터페이스(Interface)/추상클래스(Abstract Class) 중심 설계

→ 구현(Concrete)을 갈아끼우기 쉽게 

인터페이스 (Interface)	추상 클래스 (Abstract Class)
“무엇을 할 수 있는지”만 약속하는 계약. 구현할 클래스의 함수 시그니쳐(method signature)만 정해 놓음. (method signature 중심) 일반적으로 상태 (인스턴스 필드) 없음 Java 인터페이스 안의 필드는 모두 public static final(상수)로 취급되며 인스턴스별 값이 될 수 없다. - 한 클래스가 여러 인터페이스를 동시에 구현 가능. 최신 언어(Java 8+, C# 등)는 default/static 메서드로 “선택적 기본 구현”을 허용.	공통 상태(필드)와 일부 구현을 제공하는 “뼈대 클래스”. 추상 메서드(하위가 반드시 구현)와 구상 메서드(이미 구현)를 혼합 가능. 보통 단일 상속만 허용(한 클래스가 추상 클래스를 하나만 상속).

---

※ 함수 시그니처 (method signature)

- 메서드를 식별하는 “이름 + 매개변수(parameter, 타입과 순서)”의 조합. 

- return type과 throws 절은 제외

“throws 절(throws clause)”  = 메서드 선언에서 “이 메서드가 던질 수 있는 ‘체크 예외’ 목록”을 선언하는 부분. 구현/오버라이드 시 더 넓은(상위) 체크 예외로 확대하면 안 되고, 같거나 더 좁혀야 한다.

// 시그니처: pay(int)
// 아래 두 메서드는 이름과 파라미터가 같아서 『 같은 시그니처 』
void pay(int amount);
int  pay(int amount); // 컴파일 불가(반환타입만 다르면 오버로딩 아님)


// 오버로딩은 파라미터 목록이 달라야 함
void pay(long amount);     // pay(long) → 다른 시그니처
void pay(int amount, int tax); // pay(int,int) → 다른 시그니처

 

 

⚠️ 인터페이스 구현 시에는 반환 타입이 호환되어야 한다 (동일 혹은 공변 반환 타입)

     = 인터페이스 메서드를 구현(override)할 때 반환 타입을 같게 하거나 “더 구체적인(subtype)/하위 타입”으로 바꿔도 된다.

interface Repo {
    Number findId();   // 계약: Number를 반환
}

class IntRepo implements Repo {
    @Override
    public Integer findId() { // OK: Integer는 Number의 하위 타입 → 공변 반환
        return 42;
    }
}

class BadRepo implements Repo {
    @Override
    public Object findId() {  // 컴파일 에러: Object는 Number의 상위 타입(더

 

---

※ 상태 (인스턴스 필드)

- 객체(instance, 클래스=객체의 속성을 정의, 기능을 구현해놓은 코드 상태)가 개별적으로 가지고 있는 데이터(필드, field).

- 인스턴스마다 값이 다를 수 있음.

• 예: 은행 계좌 객체마다 balance가 다름 → balance가 “인스턴스 필드(상태)”.

class BankAccount {
    private int balance; // 인스턴스 필드(상태)
    public void deposit(int amount) { balance += amount; }
}

 

https://lala9663.tistory.com/31

[자바] 인스턴스(Instance)란?

실제 클래스기반으로 생성된 객체(인스턴스)는 각각 다른 멤버 변수 값을 가지게 됨 가령, 학생의 클래스에서 생성된 각각의 인스턴스는 각각 다른 이름, 학번, 학년 등의 값을 가지게 됨 new 키워드를사용하여 인스턴스 생성

 

---

※  default/static(정적) 메소드

Java 8+에서 인터페이스도 메서드의 “기본 구현”을 가질 수 있습니다.

• default 메서드
  • 인터페이스에 구현 코드를 둘 수 있게 해 주는 키워드.
  • 구현 클래스는
    • 그대로 “상속해 사용”하거나,
    • 필요하면 “override(재정의)”할 수 있음.
  • 효과: 기존 인터페이스에 새 메서드를 추가해도, 기본 구현이 있으니 옛 구현체들이 즉시 깨지지 않음(호환성 유지).
• static 메서드
  • 인터페이스 이름으로 호출하는 “유틸리티 메서드”.
  • 인스턴스(구현 클래스의 객체)가 아니라 “인터페이스 자체”에 속하며, 구현 클래스에 상속되지 않습니다.

---

 

다중 상속 (Multiple Inheritance)

- 한 Class가 여러 부모 Class를 동시에 상속하는 것

- 다이아몬드 문제 발생 가능

   (다중 상속 시 상위 공통 조상이 중복/모호하게 상속되어 어느 경로의 멤버를 써야 하는지 애매해지는 문제)

예시 : 

다이아몬드 문제 발생

struct A { void hello(); };
struct B : A {};
struct C : A {};
struct D : B, C {};

int main() {
    D d;
    // d.hello();  // 모호성 오류: 'A::hello'가 두 경로로 존재
}

 

다이아몬드 문제 해결 (가상 상속 Virtual Inheritance로 A를 단 1번만 공유)

struct A { void hello(); };
struct B : virtual A {};
struct C : virtual A {};
struct D : B, C {};
int main(){ D d; d.hello(); } // OK, A가 하나로 공유됨

 

- JAVA는 다중 상속 지원 안 함. 대신 다중 상속 효과를 인터페이스를 이용해서 구현 가능!!

   👉 Type은 다중(여러 Interface)으로 받고, 구현은 합성/위임 + 필요 시 default 메서드 보조하는 방식 

 

 

 

예시 : 

1. 여러 Interface를 한 Class가 동시에 구현

interface Cacheable { void put(String k, String v); String get(String k); }
interface Retriable { void withRetry(Runnable r); }

class Service implements Cacheable, Retriable {
    // 구현은 '합성'으로 빼서 재사용
    private final Cache cache = new Cache();        // 별도 구현체
    private final RetryPolicy retry = new RetryPolicy();

    @Override public void put(String k, String v){ cache.put(k,v); }
    @Override public String get(String k){ return cache.get(k); }
    @Override public void withRetry(Runnable r){ retry.runWithRetry(r); }
}

 

2. Interface default method로 가벼운 구현 섞기 (Java 8+)

interface Logger {
    default void log(String m){ System.out.println("[L] " + m); }
}
interface Auditor {
    default void log(String m){ System.out.println("[A] " + m); }
}
class Service implements Logger, Auditor {
    // 충돌 시 반드시 명시적으로 해결
    @Override public void log(String m){ Logger.super.log(m); }
}

---

 ② 합성(Composition) 우선 → “is-a” 상속보다 “has-a” 조립을 선호 

"is-a" 상속(inheritance) : A는 B의 한 종류이다.

- 상위의 field, method를 물려받는다(재사용) + overiding으로 특화

- type 계층으로 다형성(polymorphism) 활용

- 강한 결합, 낮은 유연성

- 취소 가능한(애매한) 관계에 쓰이면 LSP 위번, bug 유발

 

예시 :

class Animal { void move() {} }
class Dog extends Animal { @Override void move() { /* 걷기 */ } }

 

"has-a" 조립(composition) : A는 B를 가진다. A는 B를 사용해 움직인다.

- 객체가 다른 객체를 속성으로 가지고, 그 객체에게 일을 위임(delegate)해 기능을 이룬다.

- 내부에 다른 객체를 field로 둔다.

- 느슨한 결합

 

예시 :

interface Payment { void pay(int amount); }
class Card implements Payment { public void pay(int a){ /*...*/ } }
class Kakao implements Payment { public void pay(int a){ /*...*/ } }

class Checkout {                 // has-a Payment
  private Payment payment;
  Checkout(Payment p){ this.payment = p; }
  void setPayment(Payment p){ this.payment = p; } // 런타임 교체
  void process(int amount){ payment.pay(amount); } // 위임
}

 

일반화는 상속화?

일반화는 "is a kind of" 관계이다.

 

 

---

 ③ 느슨한 결합(Loosely Coupled)과 의존성 주입(DI) → 테스트/교체 용이 

 

 

---

 ④ SOLID 원칙 준수 → 확장엔 열려 있고 변경엔 닫혀 있게(Open-Closed) 

https://lxvxxu.tistory.com/1336

[Java] 객체지향 프로그래밍(OOP) - 4. SOLID란?

 

---

 

 

결국 목표는 “변화에 강한 코드”.
요구사항이 바뀌어도 수정 범위를 최소화하고,
테스트가 쉬운 구조를 만드는 것입니다.