728x90
의존성, 상속, 모듈, 조합 등 객체지향 디자인에 필요한 기술이나 키워드들을 중심으로 소제목에 대한 각자의 생각을 공유해보면서 스터디가 진행되었다. 개인적으로 기존에 작성했던 코드에 대한 반성도 많이 되었고, 또한 도움되는 지식들을 얻게 되었다.
스터디 때 공유해던 의문사항
스터디를 하면서 의문 또는 고민사항들을 공유했고, 그에 대한 의견을 들었다.
개인적으로 추가적인 고민을 해보면서 현재의 생각들을 정리해보았다.
1. 책에서 말하는 수정되기 쉬운 코드는 무엇을 말하는가?
- 책에서 말하는 수정되기 쉬운 코드라는 것은 클래스 내부에서 조건문으로 인해 분기처리되는 형태처럼 추가적인 조건들을 나열하여 객체에 불필요한 책임을 부과할 수 있는 코드
- 위와 같이 현재는 이해했지만, 다시 읽어볼 필요가 있다고 생각한다.
2. 훅 메시지가 의존성을 없애주는 것이 맞는가? 없애는 것이 아닌 약하게 해주는 것이 아닌가?
- 책에 나온 예제를 기준으로 훅 메시지를 통해 서브클래스가 수퍼클래스의 메소드를 재정의하지 않고, 훅 메시지를 통해 서브클래스의 의도를 드러내는 방법이라고 생각한다.
스터디 때 공유되었던 예제 또한 훅 메시지를 통해 수퍼클래스에서 정의된 행위를 제어한다고 생각한다.
완전히 없애주기보다는 의존성을 약하게 해주는 것이 좀 더 맞다고 판단된다.
3. (코드숨 과제 관련)TaskService는 TaskList 객체가 자기 스스로 표현할 수 없게 하지 않나?
- TaskService의 책임은 TaskList 관리해주는 것이고, TaskList객체 자체를 표현해주는 것은 아니다.
TaskService는 다른 객체로부터 TaskList에 요청한 메시지를 대신 받아주고, 대신 전달해주고, 이외에 필요한 것(예를 들어 generateId메소드)들을 제공해준다. - 다시말해, TaskList객체 책임 일부를 위임받고 TaskList을 도와주는 책임을 가지고 있다.
리스코프 치환 원칙에 위배되는 예제는?
스터디 때 언급되었던 예제를 기준으로 Swift 코드로 아래와 같이 예제 코드 2개를 작성해 보았다.
둘 다 좋은 예제는 아닌 것 같다...
// #1
class Duck {
var height: Int
init(height: Int) {
self.height = height
}
}
class RubberDuck: Duck {
override var height: Int {
get {
return 50
}
set {
//
}
}
}
var duck: Duck = RubberDuck(height: 20)
print(duck.height) // -> expected: 20, actual: 50
// #2
class Duck {
private var height: Int?
func setHeight(_ height: Int) {
self.height = height
}
func getHeight() -> Int {
height ?? 0
}
}
class RubberDuck: Duck {
override func getHeight() -> Int {
50
}
}
var duck: Duck = RubberDuck()
duck.setHeight(20)
print(duck.getHeight()) // -> expected: 20, actual: 50
RubberDuck은 Duck을 대체가능해야하나, height의 실제값이 의도한 20아닌 50이 리턴된다.
아쉬운 점
-
책을 끝까지 읽지 못했다.
728x90
'회고' 카테고리의 다른 글
2021. 02. 05 (0) | 2021.02.06 |
---|---|
2021. 02. 04 (0) | 2021.02.05 |
2021. 02. 03 (0) | 2021.02.04 |
2021. 02. 02 (0) | 2021.02.03 |
2021. 02. 01 (0) | 2021.02.02 |