[BackEnd] IoC & DIP & DI

개요

---

• Inversion of Control, Dependency Inversion Principle, Dependency Injection에 대해 학습한다.
• DIP를 위해 → IoC 개념으로 → DI를 사용하는 큰 흐름을 가지고 각 내용을 살펴본다.

 

 

1. IoC (Inversion of Control) : 제어(관리)의 역전

---

프로그램의 제어 흐름을 개발자가 아닌 프레임워크/컨테이너가 담당하는 설계 원칙이다.

1.1 제어(관리)의 두 가지 의미

• 객체 생명 주기 제어(생성, 소멸)
• 프로그램 실행 흐름 제어(언제, 어떤 순서로)

1.2 전통적 방식 vs IoC

• IoC 적용 전

class Teacher:
	def teach(self): 
		student = Student() # 내가 직접 생성
		result = student.study() # 내가 직접 호출
		return result

# main에서 내가 모든 걸 제어함
def main():
	teacher = Teacher() # 내가 생성
	result = teacher.teach() # 내가 호출

• IoC 적용 후

class Learner(ABC):
	@abstractmethod
	def study(self) -> str:
		pass

class Student(Learner):
	def study(self) -> str:
		return "학생이 공부 중이에요."
		
class CollegeStudent(Learner):
	def study(self) -> str:
		return "대학생이 공부 중이에요."
		
class Teacher:
	# DI로 구현하는 것이 가장 일반적이다.
	def __init__(self, learner: Learner):
		self.learner = learner # 외부에서 생성 받아옴 => 제어권 역전
	
	def teach(self):
		return self.learner.study()

# main, continer의 제어
def main():
    # 외부에서 제어 (IoC, DI)
    student = Student()
    teacher1 = Teacher(student)  # DI

    college = CollegeStudent()
    teacher2 = Teacher(college)  # DI

    print(teacher1.teach())  # 학생이 공부 중이에요.
    print(teacher2.teach())  # 대학생이 공부 중이에요.

• Teacher는 교육 로직에만 집중한다. (SRP 준수)
  • SRP(Single Responsibility Principle) : 단일 책임 원칙
  • 한 클래스는 오직 하나의 책임(역할)만 가져야한다.
• 외부에서 다른 Student를 Teacher에 주입 가능하다.

 

2. DIP(Dependency Inversion Principle)

---

DIP는 IoC 철학을 “무엇에 의존할 것인가”로 구체화한 설계 원칙이다.

'상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야한다. 추상화는 세부 사항에 의존해서는 안된다.’

 

구체적인 것이 아니라 추상적인 것에 의존한다. 의존 방향이 상위 → 추상 ← 하위 로 둘다 추상에 의존한다.

2.1 DIP 적용 전후 의존 관계

# DIP 적용 전
Teacher --> Student (고수준 모듈이 저수준 모듈(구체 class)에 바로 의존)

# DIP 적용 후
Teacher --> Learner <-- Student
            (추상화)      (하위 구체 클래스)
            ^ 의존 방향 역전

• Teacher : 고수준 모듈 (비즈니스 로직)
• Learner : 추상화 (인터페이스/추상 클래스)
• Student : 저수준 모듈 (구체적 구현) </aside>

from abc import ABC, abstractmethod

# 1. 추상화 정의
class Learner(ABC):  # 추상 클래스 (인터페이스)
    @abstractmethod
    def study(self) -> str:
        """공부하는 행위"""
        pass

# 2. 구체 클래스들이 추상화를 구현
class Student(Learner):
    def study(self) -> str:
        return "학생이 공부 중이에요."

class CollegeStudent(Learner):
    def study(self) -> str:
        return "대학생이 공부 중이에요."

## 새로운 학습자를 추가하더라도 ... Learner를 상속 받는 구체 클래스만 추가하면 됨

# 3. Teacher는 추상화에 의존 : Learner 인터페이스만 알고, 구체 구현은 몰라도 됨
class Teacher:
    def __init__(self, learner: Learner):  # 추상 클래스에 의존해야함! (DI)
        self.learner = learner

    def teach(self) -> str:
        return self.learner.study()

# 4. 사용 (DI + DIP)
if __name__ == "__main__":
    # 이제 모든 Learner 구현체 사용 가능!
    student = Student()
    college = CollegeStudent()

    teacher1 = Teacher(student)
    teacher2 = Teacher(college)
    
    print(teacher1.teach())  # 학생이 공부 중이에요.
    print(teacher2.teach())  # 대학생이 공부 중이에요.

 

2.2 왜 “역전(Inversion)”인가?

• 전통적 의존 방향
  • Applicatiion Layer → Business Logic → DB Layer
• DIP 적용 후
  • Application Layer → Interface ← DB Impl

 

3. Dependency Injection

---

DI는 런타임 시점의 의존 관계 결정을 코드 외부로 위임함으로써, 컴파일 타임 의존성과 런타임 의존성을 분리하는 설계 기법이다.

: 컴파일 단계에서는 소스 코드 자체(타입/인터페이스)만 확인하고, 런타임에 실제로 어떤 구체 객체를 사용할지 동적으로 결정할 수 있다.

핵심은 객체가 자신의 협력 객체를 직접 생성(new)하지 않고, 외부에서 주입 받음으로써 결합도는 낮추고 응집도는 높이는 것이다.

# Case 1 : DI 적용 X
class Teacher:
	def teach(self):
		student = Student() # 소스코드에 Student가 명시됨 -> 컴파일 타임 의존성
		return student.study()

# Case 2 : DI 적용 O
class Teacher:
    def __init__(self, student: Student):  # 타입 힌트만 있음
        self.student = student

student = Student()
student = CollegeStudent() # 다른 객체도 가능
teacher = Teacher(student) # 여기서 의존 관계 결정!

3.1 의존성

• 어떤 코드가 다른 코드에 기대고 있는 것. 즉,변경 전파 가능성을 의미한다.
• A가 B에게 의존한다 → B의 변경이 A에게 전파될 수 있다.

  class Teacher:
  	def teach(self):
  		student = Studnet() # 구체 클래스에 직접 의존
  		return student.study()
  

  • Teacher는 Student라는 구체 클래스에 소스코드 레벨에서 결합됨
  • Teacher가 협력 객체의 생성과 사용이라는 두 가지 책임을 가진다. (SRP 위반)
  • 새로운 학습자 타입을 추가할 때 Teacher 코드는 수정이 필요하다. (OPC 위반)
    • OCP(Open-Closed Principle)
    • 새로운 기능 추가는 가능하되, 기존 코드 수정은 하지 않아야 한다.

class Student:
    def study(self):
        return "공부 중이에요."

class Teacher:
    def teach(self):
        student = Student()
        return student.study()

• Teacher 클래스가 Student 클래스의 메소드를 직접 사용하면서 의존하고 있음

→ 나중에 Student 코드가 변경되면 Teacher 코드도 변경되어야함. 강한 의존

 

3.2 강한 의존을 피하기 위한 외부 의존성 주입

class Student:
    def study(self):
        return "공부 중이에요."

class Teacher:
    def __init__(self, student: Student):
        self.student = student  # 외부에서 주입받음

    def teach(self):
        return self.student.study()

student = Student()
teacher = Teacher(student) # 외부에서 만들어서, 객체 의존성 주입
print(teacher.teach())  # "공부 중이에요."

• Teacher는 클래스 내부에서 직접적으로 Student 객체에 의존하지 않고, 외부를 통해 의존한다.

→ Student 내부 구현이 바뀌어도 상관없음 → 유지보수, 테스트, 확장이 쉬워진다.

 

4. DI 방식 3가지

• 생성자 주입
• 메서드 주입
• 필드 주입

4.1 생성자 주입 → 권장. KRP Core.

• 객체를 만들 때 필요한 것을 받아서, 변동 없이 그것만 사용한다.
  • 객체를 __init__으로 받아서 붙여줌 → 의존성이 명확하다. __init__ 보면 바로 알 수 있음
  • 한번 주입되면 변경 불가능 → 불변성 보장
  • 클래스 전체에서 일관된 의존성 사용 ↔ 변경하려면 새 객체 생성
  • 매번 파라미터 전달 안해도됨

class Student: 
	# 1. 생성자 정의
	def __init__(self, name="보배"):
		self.name = name 
		
	# 2. 출력 형식(문자열) 정의
	def __str__(self):
		return self.name
		
	def study(self):
		return "학생이 공부 중이에요."
		
class Teacher:

	# 주입받을 의존성을 private 필드로 선언
	_student: Student  
	
	# 외부에서 객체를 파라미터로 받아서 생성자 주입 
	def __init__(self, student: Student):
		self._student = student 
	
	def teach(self):
		return self._student.study()
		
	# 주입받은 Student 객체를 Teacher 클래스의 모든 메서드에서 자유롭게 활용 가능하다.
	def check_homework(self):
		return f"{self._student.study()} 숙제를 확인합니다."
		
	def give_feedback(self):
		return f"{self._student} 에 대한 피드백"

if __name__ == "__main__": 
	student = Student()
	teacher = Teacher(student) # 외부에서 student를 생성하고 주입
	print(teacher.teach()) # 학생이 공부중이에요.
	print(

 

4.2 Method Injection → 일반적으로 사용하지 않는다.

• 생성자가 아닌 일반 메서드의 파라미터로 의존성을 주입 받는다.
  • 메서드마다 다른 의존성 주입 가능하다.
  • 필요한 메서드만 의존받을 수 있다.
  • 매번 파라미터로 전달해야 하는 번거로움과 명확하지 않은 의존성(함수마다 달라지기 때문)

class Student:
	def __init__(self, name="보배"):
		self.name = name

	def __str__(self):
		return self.name
	
	def study(self):
		return "학생이 공부 중이에요."
	
class Teacher:
	# 생성자에서는 의존성을 받지 않음
	def __init__(self):
		pass
	
	# 메서드 파라미터로 의존성을 주입 받음
	def teach(self, student: Student):
		return student.study()
	
	def check_homework(self, student: Student):
		return f"{student.study()} 숙제를 확인합니다."
	
	def give_feedback(self, student: Student):
		return f"{student}에 대한 피드백"
	
if __name__ == "__main__":
    student = Student()
    teacher = Teacher()  # 의존성 없이 생성

    # 메서드 호출 시마다 의존성을 주입
    print(teacher.teach(student))              # 학생이 공부 중이에요.
    print(teacher.check_homework(student))     # 학생이 공부 중이에요. 숙제를 확인합니다.
    print(teacher.give_feedback(student))      # 보배 에 대한 피드백

 

4.3 Field Injection → @Autowired

• 객체 생성 후, 필드에 직접 할당한다. teacher.student = student
  • 약간 구현부에서 setter 선언하는 것처럼 사용하는 느낌
  • 객체 생성과 의존성 주입 분리가 가능하다.
  • 불변성 보장 안됨(언제든 변경 가능)
  • 테스트 하기 어려움
  • @Autowired 이 방식인데 deprecated 추세

class Student:
	def __init__(self, name="보배"):
		self.name = name
	
	def __str__(self):
		return self.name
	
	def study(self):
		return "학생이 공부 중이에요."

class Teacher:
	def __init__(self):
		# 필드만 선언해두고 생성자에서 의존성 받지 않음
		self.student = None
	
	def teach(self): 
		return self.student.study()
	
	def check_homework(self):
		return f"{self.student.study()} 숙제를 확인합니다."
	
	def give_feedback(self):
		return f"{self.student}에 대한 피드백"
	
if __name__ == "__main__":
    student = Student()
    teacher = Teacher()  # 의존성 없이 생성

    # 필드에 직접 의존성을 주입
    teacher.student = student

    # 메서드 호출 시 파라미터 불필요
    print(teacher.teach())              # 학생이 공부 중이에요.
    print(teacher.check_homework())     # 학생이 공부 중이에요. 숙제를 확인합니다.
    print(teacher.give_feedback())      # 보배에 대한 피드백