homebrew computer club

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

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

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

인터페이스 분리 원칙은 사진1에서 보는 다이어그램에서 그 이름이 유래했다. 사진1에 기술된 상황에서, 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을, User2는 op2만을, User3은 op3만을 사용한다. 그리고 OPS가 정적 타입언어로 작성된 클래스라고 가정하자. 이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스코드는 이 두 메서드에 의존하게 된다. 이런 의존성으로 인해 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 (사실 User1과 관련된 전혀 변경되지 않았음에도 불구하고) 컴파일한 후에 다시 배포해야 한다. 이런 문제는 그림2에서 보는 것처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. 이번에..

1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다. S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고 T 타입으 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 리스코프 치환 원칙으로 알려진 이 개념을 이해하기 위한 몇 가지 예제가 있다. 상속을 사용하도록 가이드 사진1과 같이 License라는 클래스가 있다고 가정하자. 이 클래스는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출한다. License에는 PersonalLicense와 BusinessLicense라는 두 가지 하위 타입이 존재한다. 이들 두 하위타입은 서로 다른 알고리즘을 이용해서 라이선스 비용을..

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

💡백명석 님의 클린 코더스 강의를 듣고 요약한 자료입니다. 목차 1, 2강 OOP 3, 4강 Function 5강 Function Structure 6강 Form Coding Standards 조직이 일정 수준의 크기가 되면 관료적인 문서화를 요구한다. 코드를 어떻게 작성할 것인지에 대한 표준을 마련하는 것은 필요하지만, 별도로 문서화하는 것은 회의적. Comments should be rare CodingStandards가 코멘트 작성을 강제하면 어떨까? 프로그래머는 필요해서가 아니라 의무적으로 코멘트를 작성하게 될 것이다. 무의미한 코멘트가 많이 생산될수록 코멘트를 읽는 사람이 줄어들 것이다. 따라서 코멘트는 특별하게, 그것이 반드시 필요한 경우에만 작성해야 한다. Comments are failur..

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

💡백명석 님의 클린 코더스 강의를 듣고 요약한 자료입니다. 목차 1, 2강 OOP 3, 4강 Function 5강 Function Structure 6강 Form Why Clean Code 소프트웨어는 한 번 작성되면 최소 10번 이상 읽힌다고 한다. 내가 작성한 코드도 2주만 지나면 까먹기가 일쑤다. 실제 업무에서는 내 코드를 나만 보는 것도 아니다. 내가 아닌 누군가가 내 코드를 읽어야 할 수도 있다. 그래서 '돌아만 가는 코드' 말고 '읽기 쉬운 코드'를 작성해야 한다. 절차지향과 객체지향 절차지향은 프로시저가 같은 데이터에 의존하고, 프로시저가 프로시저를 의존하는 형태다. 이런 구조이기 처음엔 쉽게 만들 수 있지만 시간이 지날수록 수정이 어렵다. 그렇다면 객체지향적인 ..

객체지향 프로그래밍이란 무엇인가? 서론 객체는 현실 세계로 비유하자면 우리가 보고 느끼고 듣는 것 모든 것이 객체가 될 수 있습니다. 지금 이 글을 쓰고 있는 키보드도 하나의 객체로 볼 수 있습니다. 더 섬세하게 들어가서, 키보드를 감싸고 있는 키캡 하나하나가 모두 객체라고 할 수도 있습니다. 여기서 객체를 지향한다는 것이 무엇인지 힌트를 얻을 수 있습니다. 키캡 하나도 객체가 될 수 있다고 했습니다. 그런데 만약 내가 '키보드'라는 단어를 입력하고 싶은데 'ㅣ'를 가리키는 단 하나의 키캡만 존재한다면 어떨까요? 'ㅣ'은 키보드라는 글자를 완성하는데 필요한 요소지만, 그 자체만으로는 아무 의미가 없습니다. 'ㅋ', 'ㅂ', '..