오브젝트 (코드로 이해하는 객체지향 설계) - 조영호 저를 읽고, 제가 이해한 바를 정리한 글입니다.
이 책의 목적
- 좋은 설계란 무엇인가를 설명하는 것
- 훌륭한 객체지향 프로그램을 설계하고 유지보수하는 데 필요한 원칙과 기법을 설명하는 것
읽기 전 질문과 읽은 후 답변
Chapter 1 둘째 장 까지 읽고 <이 책의 목적>이라고 정리한 후 든 질문을 적어보았다. 그리고 Chapter 1 끝까지 읽은 후 각 질문의 답변이라고 생각하는 부분을 나름대로 채워 넣어 보았다.
- 객체지향이란 무엇인가
⇒ Chapter 2. 객체지향 프로그래밍 에서 조금 알 수 있을 것 같으며 이 책 전반을 통해 점차 알게 되어가지 않을까? - 설계란 무엇인가
⇒ 책에서 제시하는 설계란, ‘코드를 배치하는 것이다.’ - 좋은 설계란 무엇인가
⇒ 책에서 제시하는 좋은 설계란, ‘오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용 할 수 있는 설계이다.’
왜 이렇게 생각 하냐면, 우리가 하는 일이 ‘오늘 완성해야 하는 기능을 구현하는 코드’와 ‘항상 변경되는 요구사항에 맞춰 수정 시 버그를 발생시킬 수 있다는 두려움을 이길 정도로 내일 쉽게 변경할 수 있는 코드’를 짜는 것이기 때문이다. - 객체지향과 좋은 설계는 어떤 관계인가?
⇒ 책에서 제시하는 객체지향 프로그래밍은 객체간 의존성을 효율적으로 통제할 수 있는(즉, 객체 간 의존성을 적절하게 관리하는) 다양한 방법으로 내일의 변경을 매끄럽게 수용할 수 있는 가능성을 높여준다. 즉 좋은 설계의 가능성을 높여준다고 볼 수 있다.
들어가기 전, 객체지향을 대하는 Mindset
- 객체지향은 클래스가 아니라 객체를 바라보는 것에서부터 시작
- 객체는 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재임을 상기
- 협력에 참여하는 객체에 얼마나 적절한 역할과 책임을 부여하는지가 중요
모듈은
여기서 모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미한다.
- 제대로 실행되어야 하고
- 변경이 용이해야 하며
- ‘변경'은 객체 사이의 ‘의존성'과 관련되어 있다. 객체 간에 의존성이 있다는 것은 어떤 객체가 변경될 때 그 객체에 의존하는 다른 객체도 함께 변경될 수 있다는 것이다. 그러니까 의존성이 낮을수록 변경이 용이하겠다.
- ‘변경'이 ‘의존성'과 연관이 있는 것처럼 ‘의존성'은 ‘결합도'와 관련이 있다. 객체 사이의 의존성이 과한 경우를 결합도가 높다고 하고, 객체들이 합리적인 수준으로 의존할 경우 결합도가 낮다고 한다.
- 서로 의존하며 협력하는 존재인 객체에서 객체간 의존성을 완전히 없애는 것은 정답이 아니다.
- 지향해야 하는 것은 모듈이 제대로 실행되는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
- 변경이 용이하다 ← 결합도가 낮다 ← 필요한 최소한의 의존성만 유지하는 정도로 의존성이 낮다 ← 객체 간 자율성이 높으면서 응집도는 높다 ← 객체 자기 자신은 자신의 데이터를 스스로 처리하며 책임을 다한다. 그리고 객체 서로 간에는 메시지를 통해서만 협력한다 ← 캡슐화되어 객체 내부의 세부사항은 다른 객체가 알 필요 없다. ← 객체를 인터페이스와 구현으로 나눠서 객체 간에는 인터페이스만 공개하고 내부적으로 어떻게 ‘구현' 되어있는지는 숨긴다. ← 적절한 객체에 적절한 책임을 할당한다.
- 이해하기 쉬워야 한다.
- 변경이 용이한 코드라는 건 이해하기 쉬운 코드였기 때문이다.
- 이해가 쉬움 ← 그 객체가 우리가 예상하는 방식대로 동작하리라는 것을 보장 ← 자신의 데이터를 스스로 책임지는 자율적인 존재인 객체
하지만
- 어떤 기능을 설계하는 방법은 한가지 이상일 수 있다.
- 방법 간의 적절한 트레이드오프의 산물이 설계이다.
새로 알게 된 개념
✔︎ 다이어그램
- 클래스 다이어그램: 클래스의 종류와 관계를 표현하는 다이어그램
- 커뮤니케이션 다이어그램: 객체 사이의 메시지 흐름은 직관적으로 표현할 수 있는 다이어그램
- 패키지 다이어그램: 모듈이나 네임스페이스, 패키지를 표현해야 하는 경우에 사용하는 다이어그램. 패키지에 대한 상세한 정보를 제공할 필요가 있는 경우 패키지 안에 포함되는 클래스도 함께 표현함.
각각의 다이어그램의 예시가 첨부되어있고, 정말 이해하기 쉽게 그려져 있다. 하지만 책의 그림을 넣을 순 없으므로
For more information, see https://creately.com/blog/diagrams/uml-diagram-types-examples/#ClassDiagram
'Today I.. > Today I Read' 카테고리의 다른 글
[오늘, 또 일을 미루고 말았다] 당신은 신뢰할 수 있는 사람, 행복한 인생을 사는 사람 (0) | 2023.03.27 |
---|---|
[리팩터링 2판] 스터디 모집 및 시작. Chapter 1. 리팩터링: 첫 번째 예시 (0) | 2022.07.24 |
[Clean code] Chapter 12. Emergence (창발적 설계로 깔끔한 코드 구현하기) (0) | 2022.03.06 |
[Clean code] Chapter 11. System (0) | 2022.03.02 |
[Clean code] Chapter 09. Unit test (0) | 2022.02.19 |