일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 컴포즈
- compose
- 안드로이드 디자인패턴
- MVVM
- 테스트의 장점
- 단위테스트
- 코틀린
- 디자인패턴
- 안드로이드
- ViewModel
- git
- Jetpack
- Android
- dagger2
- 제한함수
- 코딩테스트
- 자료구조
- UnitTest
- 유닛테스트
- Observable
- 안정성
- mock
- 파이썬
- 깃
- Python
- Kotlin
- 공격적 프로그래밍
- Room
- rxjava
- Di
- Today
- Total
세상을 바꾸는 개발자
Delegate Pattern - kotlin (by를 사용해서 쉽게) 본문
안녕하세요 헬창코딩입니다.
오늘은 delegate pattern에 대해서 알아보도록 하겠습니다
델리게이트 패턴은 어떤 기능을 자기 자신이 처리하는 것이 아니라 다른 객체에 delegate(위임) 시켜서
그 객체가 일을 처리하도록 하는 패턴이 바로 delegate pattern입니다.
delegate pattern을 사용하는 이유가 무엇일까요??
delegate pattern의 필요성을 설명하기 전에 먼저 상속과 구성에 대한 내용을 이해해야 합니다.
흔하게 상속은 is - a의 관계라고 말하죠 예를 들어 동물이라는 클래스가 강아지라는 클래스의 부모 클래스라면
강아지 is 동물 관계가 성립을 하는 것이죠
이런 경우에는 클래스의 변수와 메서드를 상속받아서 새로 구현을 해줄 필요가 없습니다.
하지만 이러한 상속의 관계는 편리하지만 의존성이 생겨 버리기 때문에 잘 생각하고 사용을 해야 합니다.
잘못 사용을 했다가는 불필요한 의존성이 생기게 되고 유지보수나 추가적인 개발에 있어서 다양한 문제가 발생할뿐더러
코드의 유연성이 떨어지게 됩니다. 그래서 이런 해결법으로는 Composition(또는 Aggregation)관계로 구현하는 것을 권장하고 있습니다.
Composition(또는 Aggregation)은 상속이 아닌, 클래스 안에 객체를 소유하고 있는 관계를 말합니다.
delegate pattern은 Composition을 이용하는 일반적인 패턴입니다.
예제를 살펴보도록 하겠습니다.
interface Human {
fun name(): String
fun countury(): String
}
class Student : Human {
override fun name() = "홍길동"
override fun countury() = "한국"
}
class Information(student: Human) : Human {
private val human: Human = student
override fun name(): String = human.name()
override fun countury(): String = human.countury()
}
fun main() {
val human: Human = Student()
val information = Information(human)
println("이름::" + information.name())
println("나라::" + information.countury())
}
위의 코드를 보면 Human이라는 인터페이스와 Student라는 클래스 그리고 Inforation이라는 클래스가 있습니다.
Student, Information 클래스는 모두 Human 이라는 인터페이스를 상속받고 있습니다. 여기서
Information 클래스는 Student 클래스를 상속받지 않고 human 을 가지고 있습니다.
그리고 human.name() 같이 human을 호출하고 있습니다.
여기서 Delegate Pattern을 확인할 수가 있는데요
보시면 Information 클래스는 Student의 기능을 내부 변수 human에 위임했습니다.
하지만 이 구조에서는 보일러 플레이트 코드가 보이는데요
바로 information.name(), information.countury() 입니다.
만약 Human 인터페이스의 메서드가 100개라면 100개에 대한 메서드를 모두 작성해야겠죠
여기서 by 를 사용을 한다면 보일러 플레이트 코드를 줄일 수 있습니다.
interface Human {
fun name(): String
fun countury(): String
}
class Student : Human {
override fun name() = "홍길동"
override fun countury() = "한국"
}
class Information(student: Human) : Human by student
fun main() {
val human: Human = Student()
val information = Information(human)
println("이름::" + information.name())
println("나라::" + information.countury())
}
Information 클래스에 복잡한 불필요한 코드들이 사라진 것을 확인할 수 있습니다.
이렇게 코드가 깔끔해 지기 때문에 코틀린 delegate pattern을 사용할 때는 by를 꼭 사용해야겠네요!!
'안드로이드 > Design Pattern' 카테고리의 다른 글
[Android] 안드로이드 디자인패턴 3 - 3 MVVM패턴 (0) | 2021.07.12 |
---|---|
[Android] 안드로이드 디자인패턴 3 - 2 MVP패턴 (0) | 2021.07.12 |
[Android] 안드로이드 디자인패턴 3 - 1 MVC패턴 (0) | 2021.07.09 |
[Android] 안드로이드 설계원칙 (2) | 2021.07.07 |
[Android] 애플리케이션 앱설계와 원칙은? (0) | 2021.07.06 |