![[오브젝트] 04. 설계 품질과 트레이드오프](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FrL3ho%2FbtsNXsg4NIE%2FRFuGgtXgSw4WYhkfQxoRY1%2Fimg.jpg)
[오브젝트] 04. 설계 품질과 트레이드오프Life/BOOK2025. 5. 15. 07:59
Table of Contents
책에서 기억하고 싶은 내용
객체 지향의 핵심은 3가지
- 역할
- 책임
- 협력
응집도는 높고, 결합도는 느슨하게 → 객체의 행동에 초점을 맞춰라.
설계의 트레이드 오프
캡슐화
내부 구현 감추기, 수정하더라도 전체시스템에 영향이 덜 가게 파급효과를 조정할 수 있다.
변동 가능성이 높은 부분은 구현, 상대적으로 낮은 안정적인 부분을 인터페이스
외부에서는 인터페이스에만 의존하게 설계할 것.
설계가 필요한 이유는 요구사항 반영
캡슐화가 중요한 이유는 불안정 부분과 안정적 부분 분리하여 변경 통제
변경될 확률이 매우 적은 모듈은 결합도가 높아도 상관 없다. ( ex. js 기본 제공 메서드 )
데이터 중심의 시스템 문제
캡슐화 위반
변경에 취약해진다.
높은 결합도
1개가 변경 될 때, 다른 많은 변경이 생길 수 있음.
낮은 응집도
요구사항을 반영하기 위해 동시에 여러 모듈을 수정해야 함. 엉뚱한 위치에 책임이 위치하기 때문.
따라서 반대로,
우리는 캡슐화를 지키고, 낮은 결합도와 높은 응집도를 유지할 수 있도록 신경 써야한다.
데이터 중심의 설계는 “행동” 보단 “상태”에 초점을 맞추게 된다.
이는 결론적으로 너무 이른 시기에 데이터에 대해 고민 하기 때문에 캡슐화에 실패하게 된다.
떠오르는 생각
나는 이제껏 데이터 중심 설계를 많이 하고 있었구나 하는 생각이 든다.
행동부터 먼저 생각하고 어떻게하면 캡슐화를 잘 유지할 수 있을지 고민하며 구조를 생각해야겠다.
'Life > BOOK' 카테고리의 다른 글
[오브젝트] 03. 역할, 책임, 협력 (0) | 2025.05.14 |
---|---|
[오브젝트] 02. 객체 지향 프로그래밍 (3) | 2025.04.01 |
[오브젝트] 01. 객체, 설계 (0) | 2025.03.19 |
[오브젝트] 00. 시작하기 (0) | 2025.03.17 |
@RyuWoong :: #깜깜한 방에서 코딩하기
삽질의 기록과 일상을 남기는 블로그입니다. 주로 React Native를 다룹니다.
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!