5th-book-club / the-essence-of-object-orientation

객체지향의 사실과 오해 스터디

객체지향 사실과 오해

참여한 사람들

Safari, dudu, minseong ,Tiana, Eddy, Donnie, Lingo, malrang

the-essence-of-object-orientation's Issues

<재귀적 합성이란?>/ p.202

재귀적 합성이 무엇인지 아시는분 계실까요?
202 쪽 중간에 재귀적 합성이라는 객체지향적 개념을 잘 보여준다고 되어 있는데,
저자가 재귀적 합성에 대해서 설명해 주지 않네요 😢

<다형성이란?> / p.150

a라는 메소드는 성공시 어떤 성공의 메세지를, 실패시 에러가 났다는 메세지를 보내고 있으며 A객체와 B객체가 모두 수신한다고 가정 하고 둘다 실패의 메세지를 수신했다고 가정했을 때

에러가 났을 때 원하는 결과가 : a메소드가 다시 실행되도록 한다

A는 실패했다는 얼럿을 띄우고나서 a가 다시 실행되록 했고
B는 에러 메세지를 받으면 a라는 메소드가 바로 다시 실행되도록 처리를 했다

이런게 다형성인지?

<인터페이스와 구현을 분리하라. 인터페이스, 구현의 의미?> / p.220 ~ 222

책에서 저자가 앵무새처럼 인터페이스, 구현, 인터페이스와 구현을 분리하라! 이런말을 하잖아요?

저는 지끔까지 이 Interface가 유사 protocol인줄 알았고, 그렇게 이해하면서 책을 읽었는데 7장을 읽어보니 전혀 다른 말이라는걸 깨달아버렸습니다

p.220 - 221에 보면

클래스의 인터페이스는 자바의 문법을 이용해 표기했다.

class Customer {
    public void order(String menuName) {}
}

class MenuItem {}

class Menu {
   public MenuItem choose(String name) {}
}

class Barista {
    public Coffee makeCoffee(MenuItem menuItem) {}
}

class Coffee {
   public Coffee(MenuItem menuItem) {}
}

이렇게 써있는데, 이걸보고 나니 저자가 매서드 = 인터페이스 라고 표현했다는 생각이 들더라구요
(그러면 계속나오던 공용인터페이스 = public method 가 되겠네요!)

p.222에 보면,
남은 것은 order() 매서드의 구현을 채우는 것뿐이다.

class Customer {
    public void order(String menuName, Menu menu, Barista barista) {
        MenuItem menuItem = menu.choose(menuName); 
        ...
    }
}

이런식으로 써있어서, 매서드의 내부를 채우는것 = 구현 이라고 표현했다는 생각이 들었습니다
네.. 저는 책을 대충읽어서 그런지 완전히 잘못이해하고 있었네요

질문

• 다른분들은 어떻게 이해하셨나요?

결국 7장은 커피전문점이라는 하나의 도메인을 설계하는것에 초점을 맞추고 있고, 책의 핵심주제가 좋은 설계를 하는법(맞나요?) 이다보니

잡담

7장까지 읽고 제가 정리한 바는

필독!! 예쁜설계하는법

• 어떤어떤 객체들이 필요한지 식별하기 (타입 정하기)
• 객체들간의 협럭 찾기 (메시지 찾기)
• 객체에 인터페이스 만들기
• 인터페이스 내부에 실제 구현하기

저희가 이번에 수행중인 은행 창구 매니저 프로젝트를 하면서 이 책내용이 많이 생각나더라구요!
STEP2에서 은행, 손님, 점원 간의 UML을 설계하고 실제 구현하는데 도움이 됬던것 같습니다

단순히 인터페이스와 구현을 분리하는것을 넘어서, Interface나 protocol을 이용해서 더욱 높은 수준의 추상화를 해주면
더 좋은 설계를 할 수 있겠다는 생각이 들었습니다

다른분들의 생각은 어떤지 궁금합니다!!

<명세관점에서의 공용 인터페이스는 Swift에서는 static메서드인가?> / p.226

아니면 그냥 인스턴스를 생성했을 때 해당 인스턴스로 접근 가능한 private이 아닌 메서드 일지 아니면 static이나 인스턴스로 생성해 접근 가능한 메서드 둘다 포함일지...

아니면 아예 다른 개념인지 궁금합니다

<도메인, 유스케이스 & UML, flow chart 의 상관관계, 양자택일>/ p.198

198 페이지를 읽으면서
우리가 도메인 방식의 구조를 코드를 읽는 사람에게 어필하고 싶을 땐 UML 을 통해서 보여주고
유스케이스 관점을 나타내고 싶을 땐 flow chart 를 사용해 볼 수 있겠다는 생각을 했는데요,
잘 맞게 이해한 것이 맞을까요?

두개의 개념이 하나만 선택할 수 있는 개념도 아니고 모든 객체지향 설계가 두개의 특성을 같이 가지고 있다고 생각하는데,
177p ~ 176p 에 기능적이고 해결책 지향적인 접근법, 구조적이고 문제 지향적인 접근법 이렇게 양자택일 할 수 있는 것 처럼 서두를 시작한 것이 조금은 이해가 안되네요. 이부분을 어떻게 생각하시나요?
180p 에 구조를 기반으로 모델을 구축하는 편이 좋다고 안정적이라고 하는데, 이게 해결책지향적인 접근법에 비해서 라고 이해했는데, 두개가 상충 되는 개념 처럼 설명하신게 이해가 안되네요...

<클래스간의 위임이란?> / p.243

‘클래스간의 위임이 어떤 객체의 클래스가 수신된 메시지를 이해할 수 없다면 메시지를 부모 클래스로 위임한다’고 하는데
어떻게 위임할 수 있는 것이며 위임한다는 것이 대신 해결해준다는 의미인것인지?

<확장성이 좋은 설계는?> / p.182

"훌륭한 설계자는 사용자가 만족할 수 있는 훌륭한 기능을 제공하는 동시에 예측 불가능한 요구사항 변경에 유연하게 대처할 수 있는 안정적인 구조를 제공하는 능력을 갖춰야 한다."

"불확실한 미래의 변경을 예측하고 이를 성급하게 설계에 반영하는 것은 불필요하게 복잡한 설계를 낳을 뿐이다."

복잡한 설계 vs 안정적 구조?

안정적인 설계의 기준은 무엇일까요?

<스위프트는 다중 분류를 지원하지 않는걸까?> / p.234

책에서 "다중 분류"라는게

한 객체가 한 시점에 여러 타입에 속할 경우

를 말한다고 하는데요,

예를 들어

class Person {
}

class Camper: Person {
}

let marisol = Camper()

라고 되어 있을 때, marisol을 Person으로 다운캐스팅하면 marisol은 Person과 Camper 타입 모두에 속할 수 있지 않을까 생각했는데
다시 읽어보니 "한 시점"에 여러 타입에 속할 경우를 말하는 거라면
스위프트는 다중 분류는 지원하지 않는게 맞는 거라고 이해하면 될까요?!

그리고 여기서 다중 상속과 다중 분류를 헷갈리면 안된다고 하면서

"다중 상속은 하나의 타입이 다수의 슈퍼타입을 가질 수 있도록 허용하지만, 타입 정의를 생략할 수는 없다.
반면 다중 분류는 특정한 타입을 정의하지 않고도 하나의 객체가 서로 다른 타입의 인스턴스가 되도록 허용한다."

라고 설명하는데
타입을 정의한다는 말이 뭘까요?

<"메시지와 메서드의 개념적 차이?"> / p. 146

메시지와 메서드의 개념적 차이가 궁금합니다

<"증언하라"는 누구의 메소드인가?> / p.147

147p에서 보면
"증언하라" 라는 메소드는 모자장수에게 구현되어 있다고, 나와있다.
하지만, 이부분이 이해가 가질 않았다.

왕 {
let 모자장수 = 모자장수()
func 증언하라() {
모자장수.증언하다()
}

모자장수 {
func 증언하다()
}

왕.증언하라()

위 같이 구현 해볼 수 있을 꺼라 생각했다.
왜냐하면 증언하라는 왕의 행동이라고 생각했기 때문이다.

하지만, 책에선 그러지 않았다.
이부분에 대해 의견을 듣고 싶습니다.

<서브타이핑이 인터페이스 상속이고, 서브클래싱이 구현 상속이 맞는건가?!> / p.243

상속은 서브타이핑과 서브클래싱의 두 가지 용도로 사용될 수 있다고 하는데요,

서브타이핑: 서브클래스가 슈퍼클래스를 대체할 수 있는 경우, 흔히 인터페이스 상속이라고 한다
서브클래싱: 서브클래스가 슈퍼클래스를 대체할 수 없는 경우, 흔히 구현 상속이라고 한다

그런데 서브타이핑은 구현 자체를 상속하는 거라고 생각해서 서브타이핑이 구현 상속이 되고,
서브클래싱은 인터페이스만을 상속하고 구현부는 다르다고 생각을 해서 인터페이스 상속이 되어야 하는게 아닌가 라는 생각을 했습니다.

다른 분들은 어떻게 해석하셨나요?!

<인터페이스 구현과 분리가 중요하다면...> / p.169

169 페이지에
인터페이스와 구현의 분리가 중요하다 라는 내용이 있는데,
그렇다면 객채 내부에오는 메서드의 순서가
인터페이스와 구현을 기준으로 나눠주는 것과
실행 순서에 따라 배치하는 것 중
어떤 쪽이 가독성이 높다고 생각하시나요?

여러분들은 평소에 메서드의 배치(순서) 를 어떤 기준을 두고 작성하시나요?

<공용 인터페이스란?> / p.164~165

p.164, 객체 인터페이스 > 공용 인터페이스 단락에서
"내부에서만 접근 가능한 사적인 인터페이스와 구분하기 위해 외부에 공개된 인터페이스를 공용 인터페이스라고 한다." 라고 말하는데
솔직히 크게 와닿지 않는 문장입니다.

더불어, p.165 에서 모자 장수의 공용 인터페이스란 무엇인지 설명하지만... 그래서 뭐가 "공용 인터페이스 인데"라는 의문점만 남습니다.

---

ps. 우측에 Label과 Projects 꼭 선택해주세요~~~

<객체지향 프로그래밍 언어와 다른 프로그래밍 언어의 차이?> / p.149

메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 사실은 다른 프로그래밍 언어와 객체지향 프로그래밍 언어를 구분 짓는 핵심적인 특징 중에 하나라고 쓰여있는데요,

1. 메시지를 수신한 객체가 실행시간에 메서드를 선택한다는 의미가 무엇인가요?

• 컴파일 시간에는 객체가 메서드를 선택하지 않고있다가, 메시지를 수신하고나서야 메서드를 선택한다는 뜻인가요..?

2. 프로시저 호출에 대한 실행 코드를 컴파일 시간에 결정하는 절차적인 언어에는 무엇이 있는지 아시나요?? 객체지향 프로그래밍 언어와 성능상으로 차이가 있나요?

다른 언어를 전혀 모르다보니 이렇게 개념적으로 구분할 때 잘 와닿지 않는 부분이 많습니다ㅠㅠ

<우연적 속성이 불가능한 표현인가?> / p.237

우연적 속성을 객체지향에서 표현할 수 없다고 하는데
본질적인 객체에서 상태를 변하는 것을 우연적 속성으로 볼수는 없는 것인가?
예를 들어 사람 객체가 회사원의 상태를 가진다는 것은 우연적 속성에 속하는 것일까?