반응형
이 글은 엘레강트 오브젝트 새로운 관점에서 바라본 객체지향 도서를 보며 스터디한 글입니다.
책에서 주장하는 내용을 정리하였으며 예제들은 모두 코틀린 코드로 변환하여 작성하였습니다.
항상 인터페이스를 사용하세요..?
너무 비현실적인거 아닌가?
결합한다.
객체들은 서로를 필요로 합니다. 설계 시작단계에서는 객체가 어떤 일을 수행하고 다른 객체에게 어떤 서비스를 제공하는 지를 알아야하기 때문에 결합이 유용합니다. 하지만 시간이 지나면서 객체 사이의 강한 결합도가 심각한 문제가 되곤 합니다.
인터페이스는 상호작용하는 다른 객체를 수정하지 않고도 해당 객체를 수정할 수 있도록 만들 수 있습니다. 객체가 다른 객체와 의사소통하기 위해 따라야하는 계약을 일컫습니다.
interface Cash {
fun multiply(factor: Float): Cash
}
Cash의 계약에 따르는 DefaultCash 클래스
// Cash 계약
class DefaultCash(
private val dollars: Int
): Cash {
override fun multiply(factor: Float): Cash {
return DefaultCash(this.dollars * factor.toInt())
}
}
만약 금액이 필요하다면 실제 구현 대신 계약에 의존합니다.
class Employee(
private val salary: Cash
) {
}
여기서 Employee 클래스는 Cash 인터페이스의 구현 방법에 대해서는 알 필요가 없습니다. 이 것을 캡슐화라고 합니다.
잘못된 설계의 예
class Cash {
fun cents(): Int {
// logic
}
}
cents() 메서드는 어떤 것도 오버라이드하지 않기 때문에 문제가 됩니다. 이유는 이 클래스를 사용하는 다른 객체와 강하게 결합이 되기 때문입니다.
강한 결합력은 좋치 못하다.
다른 클래스로 대체가 불가능하고 오직 Cash 클래스만 사용할 수 있습니다.
class Person {
fun play() {
val cash = Cash() // Cash 클래스와 Person 클래스는 강한 결합력이 생김
val cents = cash.cents
// logic
}
}
요약
- 인터페이스를 사용하는 클래스는 인터페이스를 구현하는 클래스에서 무슨 일이 벌어지는 지 알 필요가 없다. ( 캡슐화 )
- 새로운 기능이 추가되도 느슨한 결합력 덕분에 확장성이 용이하다.
반응형
'Study > object' 카테고리의 다른 글
[엘레강트 오브젝트] 2-5장 퍼블릭 상수(Public Constant)를 사용하지 마세요 (0) | 2021.08.21 |
---|---|
[엘레강트 오브젝트] 2-4장 메서드 이름을 신중하게 선택하세요 (0) | 2021.08.18 |
[엘레강트 오브젝트] 2-2장 최소한 뭔가는 캡슐화하세요 (0) | 2021.08.16 |
[엘레강트 오브젝트] 2-1장 가능하면 적게 캡슐화하세요. (0) | 2021.08.12 |
[엘레강트 오브젝트] 1-3장 생성자에 코드를 넣지 마세요 (0) | 2021.08.11 |