지금까지 책을 읽으면서 제일 주옥같은 이야기가 많이 나왔다고 생각한다.
5장이 좀 길어서 아직 전부를 읽지는 못했다.
다 읽고나면 여기다가 추가로 작성할 예정
책임이 설계의 품질을 좌우한다.
너무 구체적이거나, 책임이 분할되어있으면 운신의 폭이 줄어든다.
너무 추상적인 책임은 정확히 뭘 하는지가 알수가 없다.
좋은 책임이란? 어떻게 가 아니라 무엇을 해야하는지 설명하는 것
어떻게 책임지냐가 있으면 너무 구체적임에 다가가는 것이다.
메서드는 어떻게가 들어있는 단어다.
생각해보면 method는 한글로 하면 방법으로 해석된다.
펑션이랑 메서드가 어떤 차이가 있는지 구분이 간다.
Function은 기능 Method는 방법
클래스에 있는 기능을 Method라고 한다
그럼 인터페이스에 적힌건 Method라고 안하나? 흠..
책임 주도 설계의 기본 아이디어는 객체들 간에 주고받는 메시지를 기반으로 적절한 역할과 책임, 협력을 발견하는 것이다.
발견하는 것이다!
What/Who 사이클
- 무엇을 할지 결정하고 누가 할지를 결정한다.
- 이번에 열차와 열차 사이의 거리를 계산할 일이 있었다.
- 열차는 어떤 경로에 위치하고 있다.
- 이떄 두 열차 사이의 거리를 재는 기능을 누가 담당하도록 할까? 고민했었는데
- 이게 여기서 나오는 What/Who 사이클과 일치해서 놀라웠다.
- 두 열차 사이의 거리를 계산하야 한다.는 What
- 이걸 누가 담당하면 좋을까? 는 Who
- 그래서 누가 할지는 경로와 열차를 모두 아는 객체에 맡기도록 했다.
묻지말고 시켜라. 메시지를 믿어라
- 이런 말들이 나오는데..
- 메시지가 이상하면 어떡할까?
- 메시지가 정상인지 처리가 가능한지 체크하는 단계는 고민이 되는 단계인데
- 메서드 외부를 무조건 외부로 간주하면 항상 방어적으로 메시지 체크가 이루어져야 한다.
- 시스템 외부만을 외부로 간주한다면 내부에서는 규칙에 맞게 사용된다는 가정하에 이러한 Validation 처리를 생략할 수도 있다.
- 이렇게 하려면(생략하려면) 상당히 많은 협의? 제도? 다른 장치? 가 필요할 것 가다.
- 어떻게 생각하면 아이템 속성마다 Valdation 어노테이션을 활용해서 사전에 들어오는 데이터를 체크할 수도 있을 것 같다.
- 또 Optional을 잘 활용해서 널이 반환될 수 있는 경우에는 반드시 Optional을 사용한다는 규칙을 만드는것도 좋을 것 같다. 하지만 Optional은 꼭 필요한 경우에만 쓰라는 얘기를 들어서 이 규칙도 좀 더 고민을 해봐야 되는 문제
오늘 나왔던 질문은
instanceOf로 이것저것 구분해서 알맞은 친구를 실행하는 이 느낌이 책에서 말하는 책임을 누가 할지 결정하는거랑 같은 느낌인가?
아니다..
- 옛날에 MessageHandler 구현체가 여러개 있고 그걸 분배해주는 분배기에 대한 이야기를 했다.
- 내가 이번에 만든 아이템을 Generic으로 받는 클래스 구현체 패턴 이야기를 했다. 관련해서는 사진으로 내일 공유.
- 간단하게 아이템의 추상화만으로 해결 가능한 문제라면 파라미터를 interface 로 대체하고 마무리
- 그렇게 되면 아이템 인터페이스의 구현체 별로 역할의 구현이 달라지게 되는 것
- 아이템 타입 별로 처리하는 클래스를 만들고 그 아이템의 처리자 역할을 담당하도록 하는 방식
- Generic 방식은 클래스를 분배해주는 단계가 필요하다.
- 분배기능은.. 기억을 더듬어서 다시 정리해야 하는 내용(TODO)
- 막 늘어날거 같지 않으면 오버로딩으로 해도 괜찮다고 생각한다.
12월 29일 수요일
남은 쪽수를 마저 진행했다.
변경이라는 강력한 적과의 전쟁에서 승리하기 위해 인간이 취할 수 있는 마지막 생존 전략은 변경해도 무방한 안전 지대와 변경했을 경우 외부에 영향을 미치는 위험 지대를 구분하는 것이다.
객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐이다.
아하~ 인터페이스 변경은 항상 신중해야 하겠다.
정하는 것도 신중하고, 변경도 신중하게. 정하는것은 어떻게가 아닌 무엇을 하는지. 역할에 따른 책임
책임이 자율적일수록 적절하게 '추상화'되며, '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 중진되고, '인터페이스와 구현이 명확히 분리'되며, 설계의 '유연성'과 '재사용성'이 향상된다.
응집도에 대해서 조금 애매한 느낌이 있었다.
응집도는 모듈 내부의 기능적인 응집 정도를 나타낸다. 라고 구글에 치니 나온다.
나는 이렇게 이야기했다.
하나의 기능, 역할이 한곳에 존재하는 것은 응집도가 높은 것이다.
어떤 코드블록을 복사해서 다른곳에 붙여넣어서 사용했다면 그것은 응집도가 낮은 것이다.
어렴풋이 맞는 말이지만 좀더 정확히 말하자면
서로 관련된 기능끼리 잘 묶여있는가
라고 정리할 수 있을 것 같다.
연관된 기능들 끼리 묶어놓으면
1. 숨길 수 있는 기능은 숨길수 있게 될 것이고
2. 그렇다면 메시지의 복잡도도 떨어질 것이고, 프로그램의 흐름도 단순해 질 수 있다.
3. 기능을 숨길 수 있게 되면서 변경에 강하게 될것이고
4. 인터페이스가 단순해져서 사용이 편리해질 것이고
5. 변경이 필요하거나 특정 기능이 필요할 때 한곳만 바라보고, 한곳만 수정하면 된다는 "확신"이 생긴다는 점
첫번째 링크는 응집도와 결합도에 대해서 그림으로 잘 설명해준다.
두번째 링크는 좀더 학문적으로 결합도와 응집도의 유형과 각 형태별 응집도의 높고 낮음, 좋고 나쁨을 설명한다.
[설계 용어] 응집도와 결합도
High Cohesion, Low Coupling, 응집도와 결합도 라는 설계관련 용어는 프로그래밍에 익숙하지 않은 사람들에게는 쉽게 익숙해지기가 처음에는 어려울 것 같아요.
medium.com
https://madplay.github.io/post/coupling-and-cohesion-in-software-engineering
결합도와 응집도는 무엇일까?
낮은 결합도(Coupling)와 높은 응집도(Cohesion)를 갖도록 설계해야 하는 이유는 무엇일까?
madplay.github.io
'기록 및 문서화 > 책' 카테고리의 다른 글
| 오늘도 개발자가 안된다고 말했다 - Part 1 가깝고도 먼 개발자 (0) | 2022.04.18 |
|---|---|
| 객체지향의 사실과 오해 6장 객체 지도 (0) | 2022.01.06 |
| 객체지향의 사실과 오해 4장 역할, 책임, 협력 (0) | 2021.12.17 |
| 객체지향의 사실과 오해 3장 타입과 추상화 (0) | 2021.12.02 |
| 초보자를 위한 C# 200제 (0) | 2021.05.02 |
댓글