이 포스팅은 다소 모호할 수 있어요.
- 다 읽고나도, 그래서 뭐 어떻게 만들라는 건데? 라는 생각이 들 수 있어요.
- 객체지향을 할 때 추구해야하는 방향에 대한 지침으로, 가볍게만 읽으시면 좋아요.
- 객체지향을 어떻게 해야할 지, 감이 안잡힐때 지침느낌으로 가볍게 참고하면 썩 괜찮아요
이런 사람이 읽으면 좋아요
- 객체지향을 어떤방향으로 짜야하는 지 모르겠어요. 뭐가좋은지도 모르겠어요.
- 'Getter대신 명령을 하라' 라는 말을 들어본 적이 없어요.
이런 사람에게는 큰 도움이 되지 않아요
- '그래서 어떻게 짜라는 건데?'. 협력방식으로 짜고 다좋은데. 구체적인 지침을 원하는 사람.
- 객체지향에 대한 감('흔히 말하는얘기들(Getter 대신 명령을 하라 등)')은 꽤 들어본 사람.
이렇게 읽으면 좋아요 : 시간을 들여 정독하는 것이 아니라. '아 그냥 이런 방식이 좋나보구나'.
공부하듯이가 아니라, 칼럼읽듯이 가볍게만 읽는게 좋아요.
'객체지향의 사실과오해'와 같은 종류의 책은
"이대로만 따르면 모든 게 해결될 것 같지만",
사실 구체적인 방법론을 알려주는 책이라기보단, 추상적인 방향성 정도만 제시해주는 책이에요.
그래서 너무 공부하듯이 읽지 않아도 돼요
객체지향 = 실세계 모방?
객체지향 : 실세계모방이라고들 많이 하죠.
꽤 많이 맞는 말이긴 하지만, 아주 약간 다른점도 있어요.
실생활의 물체가 객체지향속의 객체가 되면
아주 약간 '더' 능동적여져요 !
실사물을 모방한 객체는 더 능동적으로 변해요
객체 : 메시지를 주고 받으며 협력함.
만약 '사다리','사람' 라는 객체를 만든다면,
-사다리-
사다리 객체 : 사람이 사다리를 얼마나 올라갔는지를 알려줄 수 있음.
현실 : 사다리는 말을 하지 않음.
이와같이 현실세계의 물건을 객체지향의 객체로 옮기면,
사다리같은 수동적 물건도 더 능동적으로 변해요 !
이는 의인화(anthropomorphism)라고 하는 특징이에요 (영어는 무시하셔도돼요)
그래서 이렇게 현실의 객체와,
객체지향으로 옮긴 객체간의 사소한 작은 작은차이 때문에 ,
어떤 사람은 '객체는 모방이 아니라 은유다' 라고 표현하기도해요
(객체지향의 사실과오해의 저자 왈 p.68)
꼭 현실세계의 사소한 디테일은 전혀 옮기지 않아도 되고,
은유 정도면 되는 셈이에요. 꼭 필요한 것만 적당히 비슷하게 만들면 되지,
완벽히 모방하겠다고 필요없는것까지 모방할 필요는 전혀 없는거에요.
객체 = 역할, 책임, 협력.
협력이 뭐죠?
협력 : 객체의 요청과 응답. ( = 메소드로 구현 )
역할 = 책임?
거의 맞는 말.
굳이 엄밀히 따지면, 역할이 책임보다 약간 넓음.
그래서 뭐 하라는 말이죠?
객체는 '해줘(request)'와 '해줬다(response. 응답)'가 전부라는거에요.
역할/책임/협력 같은 내용은 다 까먹으셔도 돼요
객체의 분류
객체의 분류는 개념으로 !
개념 = 타입 (자료형)
개념, 타입은 객체의 행동에의해 분류됨.
즉 행동이 제일중요. 그 행동이 무엇이냐에따라 어떤타입이냐가 결정됨
다소 이상한? 너무 알쏭달쏭한 설명이라고 생각되실 수 있어요.
즉, 달릴수있으면(행동) 동물(자료형)이고, 먹을수있는 건 음식이고, 그런 느낌인 셈이에요.
그 외 사소한 읽을 거리
객체를 표현하는 모델
동적모델과 정적모델이 있어요.
동적모델 : 시간에따른 객체의 변화를 그림 (UML 등. 많이쓰임)
정적모델 : 시간과 무관하게, 가능한 모든 상태를 그림.
그래서 이 글을 읽으면 내 코드가 뭐가 바뀌는데?
구체적으로 !
위 내용은 되게 장황했지만 결론은.
얘기하면 클래스를 짤 때,
'왕(king)'의 클래스를 짠다고 하면,
왕이 어떤 기능(=메소드)을 해줄수 있느냐에 초점을 맞추면 되는 게 다에요.
객체지향 설계방법
- RDD(책임주도설계, Responsibility Driven Development)
객체의 협력에 관심을 기울임. 뭔진몰라도 암튼 짱좋으니까 이거대로... - 디자인패턴
디자인패턴이뭐죠?
자주 쓰는 클래스의 협력방식을 패턴화함. 협력관점에서 디자인패턴을 보면 좋음 - TDD
테스트, 구현을 작성하는 순서가 빠른피드백을 주므로 설계에 도움 됨
메서드 설계법
너무 구현에 의존하게 메서드명을 설계하면, 구현이바뀔때 메서드명이 안맞고, 사용법도바뀌어서 안좋음.
그렇다고 또 너무 추상적으로 해도, 명확성이 떨어짐
구현에 의존안하는 정도로 적당히 느슨하게. (느슨한 연결 ! )
그래서 결국 어떻게 설계하는데?
무슨 메시지(메소드, 기능)이 필요한지를 다 정리한다음에, 그걸토대로 클래스를 만들어요.
이것을 What/who 사이클 이라 불러요
(필요한 기능이 뭔지(What)를 먼저 다 식별하고나면, 그걸토대로 저절로 누구(Who)인지(클래스)가 결정된다는뜻인데. 위 첫줄만 납득하는 게 중요하지 이 what/who의 어원설명 자체가 크게 중요한건 아니에요.)
이 포스팅은 객체지향의 사실과 오해 p.1~ p.188의 내용을 정리한 것입니다.
