본문 바로가기

독서4

오브젝트 - 4. 설계 품질과 트레이드오프 01. 데이터 중심의 영화 예매 시스템 ○ 데이터를 준비하자 ○ 영화를 예매하자 02. 설계 트레이드오프 ○ 캡슐화 · 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고(구현) 외부에는 상대적으로 안정적인 부분만 공개함으로써(인터페이스) 변경의 여파를 통제할 수 있다. ○ 응집도와 결합도 · 응집도: 모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력한다면 높은 응집도 · 결합도: 어떤 모듈이 다른 모듈에 대해 꼭 필요한 지식만 알고 있다면 두 모듈은 낮은 결합도를 가진다. 클래스의 구현이 아닌 인터페이스에 의존하도록 코드를 작성해야 낮은 결합도를 얻을 수 있다. 03. 데이터 중심의 영화 예매 시스템의 문제점 ○ 캡슐화 위반 ○ 높은 결합도 ○ 낮은 응집도 단일책임원칙(SRP: Single R.. 2021. 8. 9.
오브젝트 - 3. 역할, 책임, 협력 01. 협력 - 영화 예매 시스템 돌아보기 협력: 기능 구현을 위한 상호작용 책임: 협력에 참여하기 위해 수행하는 로직 역할: 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다. - 협력 객체가 메시지를 처리할 방법을 스스로 선택한다.(자율적 존재) 자율적 존재가 되기 위해서는 자신이 알고있는 정보를 이용해 직접 요금을 계산해야 한다. (캡슐화) 메시지를 처리하던 중에 직접 처리할 수 없는 정보나 행동이 필요한 경우 또다른 객체에게 도움을 요청한다. - 협력이 설계를 위한 문맥을 결정한다. 객체의 행동을 결정하는 것은 객체가 참여하고 있는 협력이다. 협력이 바뀌면 객체가 제공해야하는 행동 역시 바뀌어야 한다. 협력 -> 행동 -> 상태 협력이 일종의 문맥(Context)를 제공한다. 0.. 2021. 8. 9.
오브젝트 - 2.객체지향 프로그래밍 1. 영화 예매 시스템 2. 객체지향 프로그래밍을 향해 - 협력, 객체, 클래스 · 어떤 객체들이 필요한지 (어떤 클래스가 필요한지 보다) 먼저 고민하라. · 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다. - 자율적인 객체(상태는 숨기고 행동만 외부에 공개) · 캡슐화: 데이터와 기능을 객체 내부로 함께 묶는 것 · 접근제어: public protected, private 등 접근 수정자 제공 · public interface: 외부에서 접근 가능한 부분 · implementation(구현): 외부 접근 불가, 내부만 접근 가능 - 프로그래머의 자유 · 클라이언트 프로그래머에게 필요한 부분만 공개하여, 불필요한 접근을 방지한다. . 클라이언트 프로그래머가 알아.. 2021. 8. 8.
오브젝트 - 1.객체, 설계 1. 티켓판매 애플리케이션 구현하기 2. 무엇이 문제인가 - 모든 모듈은 제대로 실행돼야 한다(o) - 변경이 용이해야 한다(x) => 과한 의존성 => 결합도가 높다. - 이해하기 쉬워야 한다(x) 3. 설계 개선하기 - 자율성을 높이자 · 모든 객체가 자율적인 존재가 되도록 설계를 변경(TicketSeller, Audience 등) · 캡슐화 : 객체 내부의 세부적인 사항을 감추는 것 => 객체 사이의 결합도를 낮춤 => 설계 변경이 쉬워짐. - 절차지향과 객체지향 · 절차지향: 프로세스와 데이터를 별도의 모듈에 위치시키는 방식 · 객체지향: 프로세스와 데이터를 동일한 모듈 내부에 위치시키는 방식. 어떤 책임을 할당할 것이냐에 초점을 맞춤 - 책임의 이동 · 기존: 책임이 Theater에 집중됨 · .. 2021. 8. 8.