DIP(Dependency Inversion Principle)의 줄임말로 의존 역전 원칙이라는 뜻이다.
이 원칙은 고수준 모듈이 저수준 모듈에 의존하는 것이 아닌, 저수준 모듈이 고수준 모듈에 의존하게 해야한다는 것이다.
고수준 모듈이란, 어떠한 의미 있는 단일 기능을 제공하는 모듈이다.
저수준 모듈이란, 고수준 모듈의 기능을 구현하기 위해 필요한 기능들을 구현한 모듈이다.
이 DIP 원칙을 다시 말하자면, 사용자가 상속 관계로 이뤄진 모듈을 사용할 때 하위 모듈을 직접 인스턴스하여 쓰지 말라는 것이다. 이 경우 사용자는 하위 모듈을 사용하는 것 기준으로 짜여져있기 때문에 하위 모듈의 내용에 변화가 생길 경우 사용자의 코드나 상위 모듈의 코드를 수정하게 되기 때문이다.
그래서 여러 코드들을 보면 사용자가 접촉하기 위한 인터페이스 객체를 따로 두고 해당 인터페이스에서 필요한 기능이 있는 모듈로 접근하는 방식들이 많다.
예시를 보자.
class Person {
val rightHand = BaseballBat()
}
class BaseballBat {
}
class Hammer {
}
해당 코드는 Person이 BaseballBat에 의존한 상태이다.
만약 BaseballBat이 아니라 Hammer로 바꾼다면, Person 클래스의 BaseballBat과 이어진 부분은 전부 변경시켜야 할 것이다.
그럼 어떻게 수정해야 할까
fun main() {
Person(BaseballBat("윌슨사 나무 야구방망이")).pickUp()
}
class Person(private val things: Things) {
fun pickUp() {
return things.pickUp()
}
}
interface Things {
val name: String
val power: Int
fun pickUp()
}
class BaseballBat(override val name: String) : Things {
override val power: Int = 15
override fun pickUp() {
println("[${name}]를 들었습니다. 파괴력은 $power.")
}
}
class Hammer(override val name: String) : Things {
override val power: Int = 10
override fun pickUp() {
println("[${name}]를 들었습니다. 파괴력은 $power.")
}
}
이렇게 수정할 경우 Person은 Things에만 의존하게 되고, 하위 모듈인 야구방망이와 해머 또한 Things에만 의존하게 되므로 Person을 수정하지 않아도 Things에 만족하는 다른 인스턴스로 수정이 가능해진다.
여기서 Things, Person는 고수준이고, BaseballBat과 Hammer는 저수준이다.
MVVM 패턴으로 앱을 만들때 비슷한 유형을 봤던 기억이 있다.
코드를 작성하며 알게모르게 원칙을 위배했던 적이 있던 것 같다.
코드 조금 바꾸니 다른 쪽 코드도 전부 고치는 대공사를 했던 기억이 있기 때문에.
'개발 > 정보' 카테고리의 다른 글
REST, REST API란 뭘까? (0) | 2024.04.24 |
---|---|
안드로이드 앱 성능 최적화하는 방법이 뭘까? (0) | 2024.04.24 |
객체지향 프로그래밍이 도대체 뭘까? (1) | 2024.04.09 |
안드로이드 API 레벨 별 버전, SDK, 이름 (0) | 2023.09.22 |
MVC, MVP, MVVM 패턴 비교 (0) | 2023.09.04 |
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!