[오브젝트] 챕터 08: 의존성 관리하기

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 과도한 협력은 설계를 곤경에 빠트릴 수 있다. 협력은 객체가 다른 객체에 대해 알 것을 강요한다. 다른 객체와 협력하기 위해서는 그 객체가 존재한다는 사실을 알고 있어야 한다. 01 의존성 이해하기변경과 의존성협력할 때 두 객체 사이에 의존성이 존재하게 된다. 의존성은 1) 실행 시점과 2) 구현 시점에 서로 다른 의미를 가진다.1) 실행 시점: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 한다.2) 구현 시점: 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경된다. 의존성 전이의존성은 전이될 수 있다. 이전 'Screening'의 코드를 보았을 때 Screening이 Movie, LocalDat..

• format_list_bulleted Book
• · 2025. 6. 4.
• textsms

[오브젝트] 챕터 07: 객체 분해

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 01 프로시저 추상화와 데이터 추상화현대적인 프로그래밍 언어를 특징 짓는 중요한 두 가지 추상화 메커니즘은 프로시저 추상화와 데이터 추상화다.프로시저 추상화: 소프트웨어가 무엇을 해야하는지 추상화한다.데이터 추상화: 소프트웨어가 무엇을 알아야하는지 추상화한다. 시스템을 분해하는 법을 결정하려면 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정해야 한다.프로시저 추상화를 중심으로 시스템 분해: 기능 분해(=알고리즘 분해)데이터 추상화를 중심으로 시스템을 분해: 데이터 중심으로 타입을 추상화(추상 데이터 타입) vs 데이터 중심으로 프로시저 추상화(객체 지향) 02 프로시저 추상화와 기능 분해메인 함수로서의 시스템프로시..

• format_list_bulleted Book
• · 2025. 6. 4.
• textsms

[오브젝트] 챕터 06: 메시지와 인터페이스

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 훌륭한 객체지향 코드를 위해선 클래스가 아니라 객체를 지향해야 한다. 좀 더 정확하게 말해선 객체가 수행하는 책임에 초점을 맞춰야 한다. 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다.훌륭한 퍼블릭 인터페이스를 얻기 위해서 도움이 되는 설계 원칙과 기법이 필요하다. 이런 원칙과 기법을 살펴보는 것이 이번 장의 주제이다. 01 협력과 메시지메시지는 객체들이 협력하기 위해 사용할 수 있는 의사소통 수단이다. 메시지는 오퍼레이션명과 인자로 구성되며, 메시지 전송은 여기에 메시지 수신자를 추가한 것이다. 메시지를 수신했을 때 실제로 어떤 코드가 실행되는지는 메시지 수신자의 실제 타입이 무엇인가에 달려 있다.메시지를 수신했을 때 실제로 실행..

• format_list_bulleted Book
• · 2025. 5. 21.
• textsms

[오브젝트] 챕터 05: 책임 할당하기

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 데이터 중심은 협력이라는 문맥을 벗어나 고립된 객체의 상태에 초점을 맞춰서 캡슐화를 위반하고, 결합을 높이고, 코드를 변경하기 어려워진다. 책임에 초점을 맞춰 설계할 때 어려운 것은 어떤 객체에게 어떤 책임을 할당할지 결정하기 어렵다는 것이다. 이번 장에서는 GRASP 패턴에 대해 알아볼 것이다. GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해 줄 것이다. 01 책임 주도 설계를 향해책임 중심 설계를 위해서는 다음 두 가지 원칙을 따라야 한다.- 데이터보다 행동을 먼저 결정하라- 협력이라는 문맥 안에서 책임을 결정하라 데이터보다 행동을 먼저 결정하라객체는 협력에 참여하기 위해 존재하며 협력 안에서 수행하는 책임이 객체의 존재가치를..

• format_list_bulleted Book
• · 2025. 5. 21.
• textsms

[오브젝트] 챕터 04: 설계 품질과 트레이드오프

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 설계는 변경을 위해 존재하고 변경에는 어떤 식으로든 비용이 발생한다. 훌륭한 설계란 합리적인 비용 안에서 변경을 수용할 수 있는 구조를 만드는 것이다. 객체를 단순한 데이터의 집합으로 바라보는 시각은 객체의 내부 구현을 퍼블릭 인터페이스에 노출시키는 결과를 낳는다. 이번 장에서는 영화 예매 시스템을 책임이 아닌 데이터 중심으로 설계해보고 객체지향적 설계와 어떤 차이가 있는지 보겠다. 01 데이터 중심의 영화 예매 시스템객체지향 설계에서는 두 가지 방법을 이용해 시스템을 객체로 분할할 수 있다. 상태(=데이터)를 분할의 중심축으로 삼는 방법이 있고, 책임을 분할의 중심축으로 삼는 방법이 있다.훌륭한 객체지향 설계는 데이터가 아니라 책임에 초점을 맞..

• format_list_bulleted Book
• · 2025. 5. 4.
• textsms

[오브젝트] 챕터 03: 역할, 책임, 협력

✏️, 💡,❓ 해당 이모지는 저의 생각임을 나타냅니다. 객체지향 패러다임 관점에서 핵심은 역할(role), 책임(responsbility), 협력(collaboration)이다.클래스와 상속은 객체들의 책임과 협력이 어느 정도 자리를 잡은 후에 사용하라 수 있는 구현 메커니즘일 뿐이다. 01 협력객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다.객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다.객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다. 협력이 설계를 위한 문맥을 결정한다메시지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다. 객체란 상태와..

• format_list_bulleted Book
• · 2025. 5. 2.
• textsms