오브젝트

모든 프로그램은1\. 실행중에 제대로 동작하는 것2\. 생명주기동안 간단한 작업으로 변경이 가능해야함 1\. 만약 변경이 불가능하다면 1번을 만족하더라도 개선3\. 개발자가 독해하기 편한 코드여야함위 코드에서 문제점은 Theater 클래스가 합성관계인 클래스들의 기능을

해당 인터페이스의 구현체에서 public이 아닌 메소드들은 자유롭게 수정이 가능하도록 명시하기 위해서 인터페이스에는 외부로 노출할 public 메소드들을 지정한다.커밋 링크DiscountPolicy 추상클래스를 보면실제 외부로 노출되는 메소드가 상속을 통해 구현해야하는

어떤 정보가 필요한 작업을 수행할 때 해당 정보를 가장 잘 아는 정보전문가 클래스에게 위임하고 메세지를 전송하는 방식으로 변경해 캡슐화를 할 수 있다.예를 들어서 A클래스에 B와 C클래스가 합성돼있으며 B와 C의 상태가 필요한 작업을 수행할 때 getter와 sette

영화 예매시스템을 책임이 아닌 상태를 표현하는 데이터 중심의 설계를 살펴보고 객체지향적으로 설계한 구조와의 차이점을 알아보자상태를 분할의 중심축으로 삼는 방법책임을 분할의 중심축으로 삼는 방법객체의 상태는 객체가 저장해야하는 데이터의 집합데이터 중심일 때 객체는 자신이

응집도와 결합도, 캡슐화처럼 구체적인 기준에 따라 책임을 할당하고 트레이드오프할 수 있는 기준2장: 책임 중심 코드의 대략적인 모양3장: 객체지향 프로그래밍에서 역할, 책임, 협력의 역할4장: 역할, 책임,협력이 아닌 데이터(상태)에 초점을 맞출 때의 문제점데이터보다