homebrew computer club

클라이언트-서버 모델 협력은 어떤 객체가 다른 객체에게 무언가 요청할 때 시작된다. 메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐. 객체는 희망하는 일을 메시지라는 형태로 전송하고, 수신 객체는 요청을 적절히 처리한 뒤에 응답한다. 이 메시지를 매개로하는 요청과 응답의 조합이 두 객체 사이의 협력을 구성한다. 두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버 모델이다. 협력 안에서 메시지를 전송하는 객체를 클라이언트, 메시지를 수신하는 객체를 서버라고 부른다. 협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다. 영화 예매 시스템이 있다면 이런 협력 관계를 가질 수 있다. Sc..

캡슐화를 위반한 설계를 구성하는 요소들이 높은 응집도와 낮은 결합도를 가질 확률은 극히 낮다. 따라서 캡슐화를 위반한 설계는 변경에 취약할 수밖에 없다. 데이터 중심 설계가 변경에 취약한 이유는 두 가지다. 너무 이른 시기에 데이터에 관해 결정하도록 강요한다. 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다. 데이터 중심 설계는 객체의 행동보다 상태에 초점을 맞춘다 데이터 중심 설계를 시작할 때 던지는 첫 번째 질문은 "이 객체가 포함해야 하는 데이터가 무엇인가?"이다. 데이터는 구현의 일부다. 데이터 주도 설계에서는 설계를 시작하는 처음부터 데이터를 결정하도록 강요하기 때문에 너무 이른 시기에 내부 구현에 초점을 맞추게 된다. 데이터 중심 설계에 익숙한 개발자는 일반적으로 데이..

'상태'와 '행동'을 하나의 객체로 모으는 이유는 객체 내부 구현을 외부로부터 감추기 위해서다. 여기서 구현이란, 나중에 변경될 가능성이 높은 어떤 것을 가리킨다. 객체지향이 강력한 이유는 한 곳에서 일어난 변경이 전체 시스템에 영향을 끼치지 않도록 파급효과를 적절하게 조절할 수 있는 장치를 제공하기 때문이다. 객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고, 외부에는 상대적으로 안정적인 부분만 공개함으로써 변경의 여파를 통제할 수 있다. 변경될 가능성이 높은 부분을 구현이라고 부르고, 상대적으로 안정적인 부분을 인터페이스라고 부른다. 객체 설계는 변경 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스만 의존하도록 해야 한다. 이것이 캡슐화다. 캡슐화의 정도가 응집도와 결합도에 영향..

역할, 책임, 협력 객체지향 패러다임의 핵심은 역할, 책임, 협력이다. 이것이 구현보다 중요하다. 다시 영화 예매 시스템을 보자. 위 표를 보면 알 수 있듯이 객체지향 원칙을 따르는 애플리케이션은 어떤 하나의 객체가 통제하지 않는다. 다양한 객체들이 자신의 일을 수행하면서 애플리케이션의 전체 기능을 완성한다. 여기서 중요한 점은 객체들이 '메세지'를 통해 상호작용한다는 것인데, 이것을'협력'이라고 한다. '책임'은 협력에 참여하기 위해 수행하는 로직이다. 객체가 가진 책임들이 모여 그 객체가 수행하는 '역할'을 구성한다. 협력 협력은 객체가 다른 객체에게 도움을 요청할 때 시작된다. 이것을 메세지 전송이라고 하는데, 객체가 협력할 때 사용하는 유일한 방법이다. 객체는 다른 객체의 내부 구현에 접근할 수 ..

프로그래밍 패러다임 패러다임이란, 한 시대의 사회 전체가 공유하는 이론이나 방법, 문제 의식 등의 체계를 말한다. 프로그래밍에 패러다임이 필요한 이유는, 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 하므로 불필요한 의견 충돌을 방지하기 때문이다. 티켓 판매 애플리케이션 추첨을 통해 관객들에게 무료 초대장을 발송했다. 당첨되지 않은 관객과 당첨된 관객을 구분해서 당첨되지 않은 관객은 티켓을 구매해야만 입장할 수 있는 프로그램을 만들 것이다. 첫 번째는 초대장을 구현하는 것이다. public class Invatation{ private LocalDateTime when; //초대 일자 } 그리고 티켓 클래스 public class Ticket { private Long fee; pub..