💡 의존성 역전 원칙

의존성 역전 원칙 이란

<aside> 💡

1. 상위 모듈은 하위 모듈에 의존 해서는 안되며 상위 모듈 / 하위 모듈은 모두 추상화에 의존 해야 한다.
2. 추상화는 세부 사항에 의존 해서는 안된다. 세부 사항이 추상화에 의존 해야 한다.

</aside>

• 즉, 의존성 역전 원칙을 통해 상위 계층이 하위 계층에 의존하는 의존 관계를 역전 시킴으로써, 상위 계층이 하위 계층의 구현으로 부터 독립 할 수 있게 됨
• Java에서 import 구문은, 추상 클래스 / 인터페이스 등만을 가져 오는 것이 이상적이라고 말할 수 있음
  • 하지만, 이는 현실적으로 매우 맞지 않음
  • String 같은 클래스는, 변경 되는 일이 거의 없으며 있더라도 엄격하게 통제 됨
  • 이와 같이 변경이 매우 어려운 클래스는 그대로 가져와도 무방 하게 여기고 사용
  • 따라서 DIP을 논할 때, 운영체제 / 플랫폼과 같이 안정성이 보장된 클래스 ( 환경 )에 대해서는 이 원칙이 무시 되도 좋음
  • 하지만, 우리가 직접 만든 구체적인 클래스는 안정성이 보장되지 않으므로 ( 변동성이 크기 때문에 ), 의존성을 역전 시키는 것이 좋음

안정된 추상화

• 구체 클래스 / 추상 클래스 ( 인터페이스 )의 변동성
  • 구체 클래스를 변경 한다고 해서, 추상 클래스를 변경 하는 일은 매우 적음
  • 추상 클래스를 변경 하면, 구체 클래스들은 반드시 변경 해야 함
  • 따라서, 인터페이스 ( 추상 클래스 )는 구현체 보다 변동성이 낮음
• 인터페이스의 변동성을 낮추는 것이 좋은 아키텍트 접근법

안정된 소프트웨어 아키텍처

• 변동성이 큰 구현체에 의존하는 일을 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍쳐
• 이를 구현하기 위한 방법
  • 변동성이 큰 구체 클래스를 참조 하지 말 것
    • 추상 인터페이스를 참조 할 것
    • 객체 생성 방식을 강하게 제약하며, 일반적으로 추상 팩토리를 사용하도록 강제 함
  • 변동성이 큰 구체 클래스로 부터 파생하지 말 것
    • 상속은 매우 강력하며 뻣뻣한 관계 → 변경하기 매우 어려움
    • 따라서 상속은 아주 신중하게 사용 해야 함
  • 구체 함수를 오버라이드 하지 말 것
    • 구체 함수는 추상 인터페이스가 아닌, 소스코드에 의존함
    • 구체 함수를 오버라이딩을 하여 사용한다면, 구체 함수의 의존성을 상속 받게 되는 것과 같음
    • 차라리 추상 함수로 선언하고, 각 구현체들에서 각자의 용도로 사용 할 것
  • 구체적이며, 변동성이 크다면 절대로 그 이름을 언급하지 말 것

팩토리

• 모든 언어에서 객체를 생성 하려면, 해당 객체를 구체적으로 정의한 코드에 대해 소스코드 의존성이 발생 함
• 따라서 변동성이 큰 구체적인 객체는 생성 할 때 매우 주의 해야 함
• 따라서, 객체 지향 언어에서 생성자에 의한 의존성을 제거하기 위해 추상 팩토리를 사용 하곤 함
• 추상 팩토리

  • 추상 팩토리를 사용하지 않은 경우

    class Teacher() {
    	val student = Student()
    }
    
    class Student {
    	val age = 5
    	fun getAge(): Int {
    		return age
    	}
    }
    
    application -> teacher -> student ( 구체 )
    
    application -> teacher -> student ( 추상 )
    studentImpl -> student ( 추상 ) 
    studentFactoryImpl -> studentFactory -> student ( 추상 ) 
    

    • student 객체를 Teacher 클래스 안에서 직접 하고 있음
    • 이 경우, Teacher 클래스는 Student 클래스의 생성자에 크게 의존 하고 있음
    • 만약 Student의 생성자가 변경 된다면, Student를 실제 생성하여 사용하고 있는 클래스 안에서 모두 변경을 해 주어야 함

  • 추상 팩토리를 사용 한 경우

    class Teacher(
    	private val studentFactory: StudentFactory
    ) {
    	val student = studentFactory.makeStudent()
    }
    
    interface StudentFactory {
    	fun makeStudent(): Student
    }
    
    class StudentFactoryImpl : StudentFactory {
    	override fun makeStudent(): Student {
    		return StudentImpl()
    	}
    }
    
    class StudentImpl : Student {
    	val age = 5
    	override fun getAge(): Int {
    		return age 
    	}
    }
    
    interface Student {
    	fun getAge(): Int
    }
    
    fun main() {
    	val teacher = Teacher(StudentFactoryImpl())
    }
    

    • 위 경우를 살펴 보면, Teacher 클래스는 studentFactory를 생성자를 통해 받고 있다.
    • 이를 통해 Student를 구현 하고 있는 클래스의 구체적인 생성자가 바뀌더라도 Teacher 클래스, 즉 Student 구현 클래스를 생성하여 실질적으로 사용하고 있는 클래스에서의 코드 변경이 없어진다.
    • 그렇다면, Student 구현 클래스의 의 생성자가 바뀐다면, 바뀌어야 할 곳은 StudentFactoryImpl 클래스 이다.
    • Student클래스의 객체를 사용하는 곳이 100군데인 경우를 가정 해 보자
      • 만약 추상화 / 의존성 역전 없이 Student클래스를 직접 생성하고 생성 하는 곳이 100군데 인 경우라면, 생성자가 변경 되었을 때 변경 해 주어야 할 곳은 100군데 이다.
      • 만약 위와 같이 추상 팩토리로 구조가 짜져 있다면, 생성자가 변경 되었을 때 변경 해 주어야 할 곳은 StudentFactoryImpl 한군데 뿐이다.
        • 실제 Student 객체를 사용 하는 곳에서는 Student를 Factory에서 주입 받기 때문에 전혀 영향이 없다.
    • 따라서, 구체적인 것들로 부터 추상적인 것들을 분리 한다면, 매우 매우 유지보수가 쉬워질 수 있다.
    • 추상 컴포넌트에는 일반적으로 애플리케이션의 고수준 업무 규칙을 서술한다.
    • 구체 컴포넌트에는 업무 규칙 ( 비즈니스 로직 )을 다루기 위한 필요한 세부 사항을 서술 한다.
    • 위 경우엔, StudentFactoryImpl을 main에서 생성 한 이후 계속해서 재사용 할 수 있도록 전역 변수로 저장 할 수 도 있다.