개방 - 폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 해당 내용에서의 키워드는 "확장"과 "수정" 확장에 대해 열려 있다. 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다. 수정에 대해 닫혀 있다 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다. 컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하라 사실 개방-폐쇄 원칙은 런타임 의존성과 컴파일 타임 의존성에 관한 이야기이다. 런타임 의존성 실행 시에 협력에 참여하는 객체들 사이의 관계 컴파일 타임 의존성 코드에서 드러나는 클래스들 사이의 관계 이 할인정책은 사실 이미 O..

오늘은 7장 객체 분해에 대해 이야기해보려고 한다.  일주일에 두 챕터씩 항상 꾸준히 읽고 정리를 진행하고 있는데 뒤로 갈수록 이해와 정리를 병행하여 두 챕터씩 진행하다 보니.... 양이 상당하다 7장의 예제 코드의 경우 RUBBY를 통해 예제가 나와있어 자바 개발자인 나로서는 해당 코드를 이해하기 위해 하나씩 쫓아가며 이해하려고 노력했다.. ㅠㅠ  아무튼 본론으로 한번 들어가 보자!  서론사람의 기억은 단기 기억과 장기 기억으로 분류할 수 있다. 일반적으로 우리가 기억에 접근을 할 때 곧바로 장기 기억으로 접근하는 것이 아닌, 장기 기억을 단기 기억으로 옮긴 후에 해당 기억을 처리한다.  맞다. 이전, 경선식 영어 강의를 들었을 때, 해마 공부법을 이야기하시며 이와 비슷한 이야기를 해주셨었던 기억이 났..

오늘은 이전, 5장에 이어 6장을 정리해보고자 한다.  6장에서는 이전에 나왔던 메시지에 대한 내용과 인터페이스 관련된 주제로서 이야기함을 알 수 있었다.  한번 하나씩 살펴보도록해보자!  협력과 메시지 클라이언트 - 서버모델 두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포이다.  클라이언트 협력안에서 메시지를 전송하는 객체서버메시지를 수신하는 객체협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다. 위 예제를 통해 협력관계를 파악해보도록 하자  Screening 객체는 클라이언트 , Movie는 서버로 볼수있다.  Screening 객체는 Movie에게 가격을 계산하라는 요청을 보내고 Movie는 가격 계산 서비스를 제공해줌으로써 이 메시지에 응답하게 된다.  해당 부분..

이전 내용에 대해 간략하게 요약을 해봤을 때 나는 데이터 주도설계가 아닌 책임 주도 설계를 해라 였다. 이때 책임 주도 설계에서 중요한 건 캡슐화를 강조했다.  해당 장에서는 4장의 내용에 이어 책임 주도 설계에서 책임을 할당하는 것에 대해 자세하게 나와 있었다. 그럼 한번 살펴보도록 하자! 책임 주도 설계를 향해 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 두 가지 원칙을 따라야한다고 한다. 데이터보다 행동을 먼저 결정해라 협력이라는 문맥 안에서 책임을 결정해라  데이터주도 설계 vs 책임 주도 설계  데이터주도 설계이 객체가 포함해야 하는 데이터가 무엇인가? 데이터를 처리하는데 필요한 오퍼레이션은 무엇인가? 책임 주도 설계 이 객체가 수행해야 하는 책임은 무엇인가?이 책임을 ..

이번 주 스터디에서의 목표는 3,4장을 읽는 것이 목표였다.  주말에 시간이 많이 남아 그동안 못읽었던 책들이나 내용을 공부하는 편인데, 다음 주는... 생일이나 다른 일정들이 있기 때문에 미리 평일에 조금씩 해둬야겠다..  서론은 이쯤하고 본질적인 내용을 들어가 보도록 하자  내가 생각한 이 챕터의 핵심 데이터 중심적인 설계는 지향하세요! 객체지향중 제일 중요한 건 책임입니다. 캡슐화 x 100 해당 챕터에서는 3장에 내용이 이어졌었고, 해당 챕터를 읽을수록 캡슐화의 중요성과 데이터 중심적인 설계는 하지 말아라라는 게 핵심으로 보였다.  데이터 중심의 영화 예매 시스템 객체 지향 설계에서는 두가지의 방법을 이용해 시스템을 객체로 분할하는 것이 가능하다. 상태 ( 데이터 )를 분할의 중심축으로 삼는 방법..

최근 회사에서 매주 이슈 체크 및 코드 리뷰를 진행하기로 하여, 이때 전략 패턴에 대해 소개를 해주시고 공유를 받아 연습해볼 겸 한번 작성해 보았다. 취준 당시, 디자인 패턴에 대해 항상 나중에 해봐야지... 라고 생각했었는데 요즘이 적기라 생각이 들었고 추후에 도움을 많이 받을 것 같아 정리해보려고 한다. 정의부터 한번 알아보도록 하자 전략 패턴 ( Strategy pattern ) 정책 패턴 (policy Pattern)이라고도 불리며, 실행중에 알고리즘을 선택할 수 있게 하는 행위 소프트웨어 디자인 패턴이라고 위키백과가 말하고 있다. 객체의 행위를 직접 수정하지 않고 전략을 바꿔줌으로서 행위를 유연하게 확장한다는 장점을 가지고 있다. 나는 제공해주셨던 뉴스 예제를 최근 연습하고 있는 코틀린을 적용해..

해당 챕터에서는 객체지향 패러다임의 핵심 3가지에 대해 이야기하고 있다.   서론 객체지향 패러다임의 핵심은 다음과 같다. 역할 (role) 책임 (responsibility)협력 (collaboration) 객체들의 책임과 협력이 어느 정도 자리 잡은 후 사용할 수 있는 구현 메커니즘 클래스상속객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 발생한다.   나는 다음과 같은 구절이 정말 나에게 많이 와닿았다.  "애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지를 고민하지 않은 채 너무 이른 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다 "  맞다. 진행했던 프로젝트..

지난 9월 회고록을 보니.... 너무 대충 쓴 느낌이 강하게 든다. ㅠㅠ 그렇기에 심기일전해서 다시 써보려고한다. 최근 생활 파일럿 프로젝트 이후, 회사 업무를 본격적으로 하며 현재 개발을 진행 중에 있다. 회사에서 근무를 하며, 확실히 이전 회사를 입사하기 전보다 더 많은걸 느낄 수 있었다. 설계의 중요성, 아키텍처 구상 등등... 사실 이론적으로나 머릿속으로 알고 있었고 프로젝트에서도 최대한 진행하려고 노력했다. 하지만, 그동안 진행을 하며 애들 장난인 느낌이 들었고 아직 완벽하지 않다는 생각이 마구 들었다. 나는 여기서 어디일까 생각을 해보니 절망의 계곡 이 부분인 것 같았다. 그렇다고 해서 좌절보다는 오히려 알아야 할 내용이나 공부할 내용들이 많기에 다행이라고 생각했다. 정확한 정보는 아니지만, ..