21일차. IT 개념 정리

---

**객체지향 프로그래밍(OOP)**에서 **“has-a”**와 **“is-a”**는 클래스 간의 관계를 설명할 때 자주 쓰이는 핵심 개념입니다.
두 개념은 각각 **구성(Composition)**과 **상속(Inheritance)**의 관계를 의미합니다.

---

🔹 has-a 관계 (구성, Composition)

✅ 개념

• 한 객체가 다른 객체를 포함하고 있는 관계입니다.
• 즉, “A는 B를 가진다(has a)” 형태로 표현됩니다.
• 클래스 간의 협력 관계를 나타내며, 상속보다 유연한 구조를 제공합니다.

💡 예시

➡️ 여기서 Car 클래스는 Engine 객체를 속성으로 포함하고 있습니다.
즉, **“자동차는 엔진을 가진다(Car has an Engine)”**가 됩니다.

---

🔹 is-a 관계 (상속, Inheritance)

✅ 개념

• 한 클래스가 다른 클래스로부터 상속받는 관계입니다.
• 즉, “A는 B이다(is a)” 형태로 표현됩니다.
• 상속 관계는 일반화-특수화 관계(Generalization-Specialization)로 이해할 수 있습니다.

💡 예시

 

➡️ Dog 클래스는 Animal 클래스를 상속받았기 때문에,
**“개는 동물이다(Dog is an Animal)”**라는 관계가 성립합니다.

---

🔍 차이점 정리표

구분has-a 관계is-a 관계

 

의미	포함(Composition)	상속(Inheritance)
관계 표현	A has a B	A is a B
구조	한 클래스가 다른 클래스를 멤버 변수로 가짐	한 클래스가 다른 클래스를 상속
예시	자동차는 엔진을 가진다	개는 동물이다
장점	유연하고 결합도가 낮음	코드 재사용이 용이함
단점	코드 중복 가능성 있음	결합도가 높고 유연성이 낮음

---

💬 핵심 요약

• has-a → “속성” 관계 (포함)
• is-a → “계층” 관계 (상속)
• 권장 방식: 현대 OOP에서는 상속보다는 구성(Composition)을 우선하는 것이 유지보수에 더 유리합니다.
  👉 “상속보다는 구성을 선호하라(Prefer composition over inheritance)”는 유명한 원칙입니다.

 

---

🔹 의존관계 (Dependency)

✅ 개념

• 한 클래스가 다른 클래스를 잠깐 사용하는 관계입니다.
• 즉, **일시적인 관계(temporary relationship)**로, 메서드 내부에서만 사용하는 경우가 많습니다.
• 클래스 간의 **약한 결합(weak coupling)**을 의미합니다.

💡 예시

 

 

➡️ Report 클래스는 Printer 객체를 메서드 안에서만 잠시 사용합니다.
즉, “보고서를 생성할 때 프린터가 잠시 필요하다”는 관계입니다.
생명주기가 공유되지 않고, 잠시 의존하는 것이 포인트예요.

---

🔹 연관관계 (Association)

✅ 개념

• 한 객체가 **다른 객체를 속성(필드)**으로 가지고 있는 관계입니다.
• 즉, **지속적인 관계(persistent relationship)**로, 객체 간의 연결이 오래 유지됩니다.
• **has-a 관계(구성)**의 일종이라고 볼 수 있습니다.
•  

➡️ Car 클래스는 Engine 객체를 속성으로 항상 보유합니다.
즉, “자동차는 엔진을 가진다(Car has an Engine)”처럼 지속적인 관계를 유지합니다.

---

🔍 차이점 정리표

구분의존관계(Dependency)연관관계(Association)

관계의 지속성	일시적 (메서드 호출 시만)	지속적 (객체가 존재하는 동안 유지)
사용 위치	메서드 내부	클래스의 필드(속성)
결합도	낮음 (loosely coupled)	비교적 높음 (strongly coupled)
방향	단방향	단방향 또는 양방향 가능
예시	보고서가 프린터를 일시적으로 사용	자동차가 엔진을 가짐

---

💬 핵심 요약

• 의존관계 → “잠깐 빌려 쓰는 관계” (메서드 안에서 사용)
• 연관관계 → “항상 가지고 있는 관계” (필드로 보유)

👉 즉, 의존은 순간적, 연관은 지속적입니다.

 

 

---

**IoC(Inversion of Control)**와 **DI(Dependency Injection)**는 객체지향 프로그래밍, 특히 스프링(Spring) 같은 프레임워크에서 자주 등장하는 개념이죠.
두 용어는 비슷하게 들리지만, 포괄 관계에 있습니다.
즉, DI는 IoC를 구현하는 한 가지 방법이에요.

---

🔹 IoC (Inversion of Control, 제어의 역전)

✅ 개념

• **객체의 생성과 제어 권한을 개발자가 아닌 외부(프레임워크)**가 가지는 개념입니다.
• 원래는 프로그램이 직접 객체를 만들고 관리했지만, IoC에서는 **컨테이너(Spring Container)**가 대신 이 역할을 수행합니다.
• 즉, “객체의 제어 흐름이 뒤집힌다”는 뜻입니다.

💡 비유

👉 개발자가 직접 요리를 하지 않고, 레시피만 전달하면 주방장이 대신 요리해주는 구조입니다.

💻 예시 (IoC 없이 직접 제어)

 

class Chef { void cook() { System.out.println("요리 중..."); } } class Restaurant { Chef chef = new Chef(); // 직접 생성 (제어 주체: Restaurant) void order() { chef.cook(); } }

➡️ Restaurant이 Chef 객체를 직접 생성하고 관리하므로, 제어의 주체가 Restaurant입니다.

---

💻 예시 (IoC 적용)

 

class Chef { void cook() { System.out.println("요리 중..."); } } class Restaurant { private Chef chef; // 외부에서 주입받음 Restaurant(Chef chef) { this.chef = chef; } void order() { chef.cook(); } }

➡️ 이제 Restaurant은 Chef를 직접 만들지 않고 외부에서 받기만 합니다.
이때 Chef 객체를 주입해주는 역할을 **IoC 컨테이너(Spring)**가 담당합니다.
이런 식으로 객체 생성의 제어권이 역전된 것이 IoC입니다.

---

🔹 DI (Dependency Injection, 의존성 주입)

✅ 개념

• IoC의 구체적인 구현 방식 중 하나로, 객체 간의 의존 관계를 외부에서 주입하는 것을 말합니다.
• 즉, “A가 B를 필요로 한다면, A가 직접 B를 만들지 않고 외부에서 넣어준다”는 개념이에요.

💡 DI의 주요 방식

방식설명예시

생성자 주입(Constructor Injection)	생성자를 통해 주입	Restaurant(Chef chef)
세터 주입(Setter Injection)	setter 메서드를 통해 주입	setChef(Chef chef)
필드 주입(Field Injection)	@Autowired로 직접 필드에 주입	@Autowired private Chef chef;

---

🔍 차이점 정리표

구분IoC (제어의 역전)DI (의존성 주입)

개념	객체의 제어권을 프레임워크가 가지는 것	객체의 의존 관계를 외부에서 주입하는 것
범위	더 넓은 개념 (포괄적)	IoC를 구현하는 한 방법
역할	객체 생명주기 전체 제어	필요한 의존 객체를 연결
주체	IoC 컨테이너	IoC 컨테이너가 수행하는 구체적 동작
예시	스프링이 Bean을 생성, 관리	@Autowired로 객체를 주입

---

💬 핵심 요약

• IoC는 “객체의 제어권을 프레임워크가 가져간다”는 큰 개념
• DI는 “의존 객체를 외부에서 주입한다”는 IoC의 구현 방식

👉 한마디로 정리하면,

“DI는 IoC를 실현하는 방법이다.”