본문 바로가기

책

 (76)
04 역할, 책임, 협력 이 장에서는 이전 장에서 추상적으로 말하던 "협력", "책임", "역할"에 대해 보다 구체적으로 말한 장이라 생각합니다. 그렇기에 지금까지 보았던 챕터중 가장 핵심적이며 도움되는 장이라고도 생각합니다. 4장에서 가장 기억에 남는 내용은 ,책의 제목과는 무관하게도, TDD에 대한 내용이였습니다. 해당 내용은 챕터의 마지막 부분에 짧막하게 나오지만 객체지향 패러다임과 TDD를 엮어 이야기를 했다는 점이 특히 기억에 남습니다. 협력 요청하고 응답하며 협력하는 사람들 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작된다. ... 결과적으로 협력은 다수의 요청과 응답으로 구성되며 전체적으로 협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다. 제가 생각하는 협력의 핵심은 "다수", "요청과 응답"이라고 ..
5장 책임 할당하기 4장에서는 책임중심의 접근법이 아닌 데이터중심의 접근법의 문제점을 짚어보았습니다. 그리고 5장에서는 어떻게 해야 책임을 잘 할당할 수 있는지를 언급하였습니다. 기억에 남는 접근법은 총 두개가 있는데 하나는 처음에 설계를 할 때부터 GRASP 패턴으로 접근하는것 다른 하나는 절차지향적으로 코드를 먼저 작성하고 이를 리팩토링 하는 것입니다. 다행히도 GRASP 패턴의 경우 이미 1~4장까지 언급한 내용과 동일하다는 것입니다. 객체에게 할당된 책임이 협력에 어울리지 않는다면 그 책임은 나쁜 것이다. 객체의 입장에서는 책임이 조금 어색해 보이더라도 협력에 적합하다면 그 책임은 좋은 것이다. 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. 이는 "객체지향의 사실과 오해"라는 책에서도 나오는 대..
4장 설계 품질과 트레이드오프 4장에서는 1~3장까지 책에서 이야기해온 책임주도 설계가 가지는 특징들을 응집도와 결합도를 위주로 설명한 장이였습니다. 특히 1~3장에서는 책임 주도 설계 방식으로 구현하는 방법및 장점들을 위주로 설명했지만 4자에서는 설계를 할 때 객체가 가지는 데이터를 중심으로 설계 했을때 생기는 단점에 대해 언급하며 이야기를 풀어나갔습니다. 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다. 객체지향 설계를 "결합도"와 "응집도"를 바탕으로 설명하는 글입니다. 결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙이 있다. 객체의 상태가 아니라 객체의 행동에 초점을 맞추는 것이다. 이전 장에서 계속 이야기한 내용입니다. 포스팅을 하며 문득 든..
3장 역할, 책임, 협력 3장에서는 그 동안 이야기 하였던 역할, 책임, 협력을 보다 상세하게 설명하는 챕터였습니다. 3장을 다 읽은 지금 가장 기억에 남는 것 하나를 고르자면 역할은 슬롯과 같다는 말이였던것 같습니다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 과정에서 드러난다. 협력을 생각할때 중요하게 여겨야 하는 것중 하나라고 생각합니다. 1. 이처럼 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고 한다. 2. 객체가 협력에 참여하기 위해 수행하는 로직을 책임이라고 부른다. 3. 객체들이 협력 안에서 수행하는 책임이 모여 객체가 수행하는 역할을 구성한다. 그 동안 자주 언급되었던 협력, 책임, 역할을 추상적으로 설명하는 것이 아닌 구체적으로 이야기하였기에 3장에서 가장 중요한 부분이라 ..
2장 객체 지향 프로그래밍 주요 키워드 도메인 1장에서는 객체지향 프로그래밍을 공부하기 앞서 어떠한 코드가 좋은 코드인지 알려주는 내용이였다면 2장에서는 객체지향 프로그래밍하면 빠질수 없는 "다형성", "캡슐화", "접근제어자"같은 개념들을 위주로 설명하는 파트였습니다. 객체지향의 핵심 키워드를 다시 짚어가며 공부를 했기에 복습한다는 느낌으로 읽었고 제가 중요하다고 느낀것들을 인용하고 만약 제가 따로 코멘트 할 것이 있다면 따로 남기고자 합니다. 진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 1장에서도 그랬듯 2장의 서두에서 객체지향의 본질은 클래스가 아닌 객체라고 언급하는 것을 확인할 수 있습니다. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 1장의 말..
03 타입과 추상화 추상화는 현실에서 출발하되 불필요한 부분을 도려내가면서 사물의 놀라운 본질을 드러나게 하는 과정이라고 할 수 있다. 3장에서 말하는 추상화에 대한 개요를 언급하는 부분이라고 생각합니다. 추상화 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. 복잡도를 낮추기 위해 추상화는 두 차원에서 이뤄진다. - 첫번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것이다. - 두번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것이다. 3장에서는 추상화의 정의와 두 가지 차원들이 어떻게 실생활에 적용되고 또 어떻게 코드로 적용되는지를 설명합니..
02 이상한 나라의 객체 키워드 상태 행동 프로퍼티 프로퍼티 값 링크 상태와 행동간의 관계 CQS 의인화 은유 특징 객체는 상태를 가지며 상태는 변경 가능하다. 객체의 상태를 변경시키는 것은 객체의 행동이다. 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다. 행동의 순서가 결과에 영향을 미친다. 객체는 어떤 상태에 있더라도 유일하게 식별 가능하다. 객체의 행동은 상태에 영향을 받는다. 객체의 행동은 상태를 변경시킨다. 상호작용이 현재의 상태에 어떤 방식으로 의존하는가 상호작용이 어떻게 현재의 상태를 변경시키는가. 객체는 상태를 가지며 상태는 변경 가능하다. 객체의 상태를 변경시키는 것은 객체의 행동이다. 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 수 있다. 행동의 순서가 실행 결과에 영향을 미친다. 정리..
01 협력하는 객체들의 공동체 시너지를 생각하라. 전체는 부분의 합보다 크다. 우아한 테크 코스에 떨어지고 객체지향이라는 패러다임을 제대로 공부하고자 기록합니다. 01장에서는 객체지향프로그래밍이라는 개념을 짚고 넘어가는 장이였다고 생각합니다. 목차에는 다음과 같이 이루어져 있습니다. 이 중에서 제가 인상깊게 읽은 부분은 아래와 같습니다. 역할과 책임, 협력 관점에서 본 객체지향 여러 객체가 동일한 역할을 수행할 수 있다. 역할은 대체 가능성을 의미한다. 각 객체는 책임을 수행하는 방법을 자율적으로 선택할 수 있다. 하나의 객체가 동시에 여러 역할을 수행할 수 있다. 책에서 제시한 내용은 대체로 그동안 무의식적으로 사용하고 있던 추상화, 다형성, 캡슐화의 의미를 풀어서 설명했다고 생각합니다. 그렇기에 그동안 한마디로 사용하고 있었지만 ..
1장 객체, 설계 주요 키워드 자율성 캡슐화 응집도 객체지향 책임의 이동 의존성 의인화 데이터, 프로세스 해당 장에서 제시하는 코드는 "자율성", "책임", "응집도"등 모든 면에서 객체지향스럽게 작성하지 않은 코드들입니다. 즉 해당 코드에서 나타나는 여러 문제점들을 차차 수정해나가며 공부를 해나가도록 저자는 유도를 하고 있습니다. 그리고 저는 이를 따라가고자 합니다. 1장에서 구현한 프로그램은 티켓을 판매하는 프로그램으로 UML은 다음과 같습니다. 그리고 이러한 UML을 바탕으로 구현한 코드는 다음과 같습니다. public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSelle..
클린코드(Clean Code)를 읽고 클린 코드 (Clean Code) - 애자일 소프트웨어 장인 정신 지은이 : 로버트 C. 마틴 옮긴이 : 박재호, 이해영 출판사 : 인사이트(insight) ❓책을 읽게된 이유 이 책을 처음 접한 것은 2022년 우아한테크코스(이하 우테코) 5기에 지원하였을때이다. 당시 우테코에서는 과제를 진행하며 클린한 코드를 작성하는 것을 요구 했다. 당시 나는 클린한 코드에 대해 아는 것이 없었기에 부랴부랴 클린코드를 사서 목차 수준만 간단하게 눈으로 훑고 우테코 5기를 진행하였다. (그러나 학교와 병행하며 하기에는 너무 시간이 없어 결국 우테코 프리코스를 중간에 포기해야 했다.) 그리고 1년이 흘러 우테코 6기에 다시 도전하고 실패하며 “실패는 성공의 어머니라”는 말을 곱씹으며우테코 측에서 제시해준 백엔드 개발자..

티스토리툴바