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

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

해당 챕터에서는 영화 예매라는 예제를 초점으로 이야기를 이어가고 있다.  하나씩 살펴보자  요구 사항 해당 예제는 다음과 같이 요구사항을 구분지었다. 영화영화에 대한 기본정보 상영 실제로 관객들이 영화를 관람하는 사건 우리가 CGV등 각각의 영화를 예매할 때 해당 영화의 정보, 각 CGV별 할인정책이 다름을 알 수 있다.  위 예제를 사건으로 이야기 해보자면 큰 카테고리 두가지를 두고 그 밑의 ( 할인정책,  할인조건 ) 등을 생각해볼 수 있을것이다.  여기서 나는 아! 큰 상위 모듈을 기반으로 하위를 차례대로 생각하는구나 다른말로 마인드 맵이 떠올랐다.  객체지향 프로그래밍을 향해 객체지향은 객체를 지향한다.우리는 객체지향 프로그램을 작성할때 어떤 클래스가 필요한지 고민한다. 하지만 이는 객체지향의 본..

최근 블로그와 링크드인을 작성하는 재미에 푹 빠져 살고 있다.  항상 노션으로만 정리를 하였는데 오브젝트를 기점으로 읽고 있는 책들에 대해 하나하나씩 연재를 진행해보고자 한다.  (계속 글도 쓰다보면, 쓰는 능력도 늘겠지란 생각을 가지며)  해당 책은 확실한 이해를 돕기 위해 코드와 함께 설명을 이어간다. 코드에 대한 내용은 github에 적고 개인적 견해 및 이론에 대한 내용은 블로그에 적으며 진행하고자 한다.  객체 , 설계 로버트 글래스는 이론 , 실무 중 어떤 게 먼저일까에 대해 대한 물음에 실무가 먼저라고 이야기했다.  많은 사람들과 당장 개발을 접한지 얼마 안 된 친구들도 이론이 없어서.... 개발 전 이론을 탄탄히 잡고 시작할래라고 말하는 사람들이 대다수였다.  하지만 로버트 글래스는 다음과..

최근 인프런 : 객체지향 프로그래밍 강의를 보며 객체지향에 대해 지식을 다시 한번 점검하고 쌓고 있다.  모든 내용이 중요하지만 그래도, 꼭 내기준에서 남겨놔야 할 것 같은 내용들에 대해 재 정리를 하며 기록하고자 한다. 캡슐화 ( Encapsulation ) 데이터 + 관련 기능 묶기  객체가 기능을 어떻게 구현했는지 외부에 감추기 구현에 사용된 데이터의 상세 내용을 외부에 감추는 것정보은닉 ( Information Hiding) 의미 포함 데이터를 외부에 감추는것을 의미 정보은닉과 캡슐화를 구분 지어 표현하였지만, 최근 캡슐화에 정보은닉을 포함하여 표현한다.왜쓸까? 외부의 영향 없이 객체 내부 구현 변경이 가능하기 때문  캡슐화를 하지 않는다면 어떻게 될까? 다음은 요구사항의 변경으로서, Accoun..

해당 내용들은 인프런 : 객체지향 프로그래밍 입문을 토대로 작성한 글입니다.  시간이 흘러갈수록, 작성 시간이 점점 증가하는 이유?코드 분석 시간의 증가코드 변경 시간의 증가소프웨어의 가치변화Software maintenance is not “keep it working it like before.” It is “Keep being useful in a changing world”낮은 비용으로 변화할 수 있어야 한다.이를 위한 방법패러다임객체지향 , 함수형 , 리액티브 등코드 , 설계 , 아키텍처DRY, TDD , SOLID , DDD ,…클린 아키텍처, MSA , …업무 프로세스 / 문화애자일 , DevOps, …객체지향에서 크게 비용을 낮추는 방법캡슐화 + 다형성(추상화)