독서 기록11 [오브젝트] 10장 - 상속과 코드 재사용 1. 개요중복된 코드를 제거하고 코드를 재사용하고 싶다는 욕망을 가져본 적이 있을 것이다.이번 장에서는 코드 재사용에 대해 살펴보고 그 기법 중 하나인 상속에 대해 자세히 알아본다.2. 중복 코드중복 코드가 안 좋은 이유중복된 코드는 변경을 방해한다.요구사항이 변경 됐을 때 중복된 코드가 많다면 그 코드를 모두 수정해야 한다.각 코드를 수정해도 되는지 일일이 테스트하며 요구사항 변경을 해야 한다. 이 때문에 중복 코드가 있으면 코드를 수정하는데 필요한 노력이 몇 배로 증가된다.어디서 오류가 생길지 모르는 중복된 코드를 변경해야 하기 때문이다.저자는 중복 코드는 마치 시한폭탄과 같다고 비유할 정도이다.중복 코드를 판단하는 기준중복 코드를 판단하는 기준은 의외로 변경이다.요구사항에 의해 로직을 변경할 때, .. 2024. 6. 16. [오브젝트] 9장 - 유연한 설계 1. 개요8장에서는 의존성에 대해 살펴보고 여러 의존성 관리 기법들을 알아보았다.이번 장에서는 의존성을 관리하기 위한 몇 가지 원칙을 배우게 된다.2. 개방-폐쇄 원칙개방-폐쇄 원칙개방-폐쇄 원칙(Open-Closed Principle, OCP)은 '모든 개체는 확장에 대해 열려 있고, 수정에 대해 닫혀 있어야 한다'는 원칙이다. 여기서 확장은 애플리케이션에 새로운 동작이 추가되어 기능이 늘어나는 것을 의미한다.수정은 기존 코드가 수정되는 것을 의미한다.런타임 의존성, 컴파일타임 의존성과의 관계앞서 컴파일타임은 코드 레벨과 관련이 깊다는 것을 보았다.개방-폐쇄 원칙은 '컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 변경할 수 있음'으로도 볼 수 있다. 런타임 의존성과 컴파일타임 의존성을 구분하기 위.. 2024. 6. 15. [오브젝트] 8장 - 의존성 관리하기 1. 개요객체지향 설계를 위해 높은 응집도를 가진 객체를 만들게 된다.응집도가 높은 객체는 한 가지 일만 잘하기에 다른 객체와 협력이 필요하다.응집도가 높아질수록 자연스럽게 협력도 늘어난다. 하지만 협력을 하기 위해서는 다른 객체를 알아야 한다.즉 협력의 과정에서 의존성이 생기게 되는 것이다. 협력을 위한 적절한 의존성은 유지하되, 변경을 막는 과도한 의존성은 제거해야 한다.이를 의존성 관리라고 부른다.2. 의존성이란?실행 시점 의존성런타임 의존성(run-time dependency)이라고도 부를 수 있다.애플리케이션의 실행 시점에서 의존하는 객체가 정상적으로 동작하려면, 의존 대상 객체가 반드시 존재해야 한다. 구현 시점 의존성컴파일 타임 의존성(compile-time dependency)이라고도 불린.. 2024. 6. 13. [오브젝트] 7장 - 객체 분해 내용 정리: 20240410 TIL 1. 개요 복잡한 문제를 단번에 해결하는 것은 어렵다. 그 문제를 해결하기 위해서는 너무 많은 정보가 필요하고, 우리의 머리는 이를 버티지 못한다. 이처럼 문제 해결에 필요한 정보가 용량을 초과하는 경우를 인지 과부하(congitive overload)라고 한다. 인지 과부하를 막기 위해 우리는 복잡하고 큰 문제를 해결할 수 있는 작은 문제로 나눈다. 추상화를 사용해 정보의 핵심만을 남기며 문제를 분해(decomposition)한다. 프로그래밍 언어도 추상화를 통해 복잡성을 극복하며 발전해 왔다. 기계어는 어셈블리어로 추상화되고, 어셈블리어는 고수준 언어로 추상화되었다. 프로그래밍 패러다임도 추상화와 분해의 관점에서 살펴보자. 2. 프로시저 추상화와 데이터 추상화 프로.. 2024. 4. 14. [오브젝트] 6장 - 메시지와 인터페이스 내용 정리: 20240326 TIL 1. 개요 6장에서는 인터페이스 구성에 집중한다. 좋은 인터페이스를 얻기 위해 적용할 수 있는 다양한 원칙들을 알아보자. 2. 메시지 메시지의 구성 메시지 전송은 한 객체가 다른 객체에게 도움을 요청하는 것이다. 여기서 요청하는 객체를 클라이언트, 요청을 받는 객체를 서버라고 한다. 메시지 전송은 메시지 수신자(message receiver), 오퍼레이션명(operation name), 인자(argument)로 구성된다. bag.hold(ticket); 위 코드에서 hold는 오퍼레이션명, ticket은 인자, bag은 메시지 수신자이다. bag이라는 메시지 수신자에게 ticket이라는 인자를 주며 hold라는 오퍼레이션을 시키는 것이다. 오퍼레이션명과 인자를 합쳐 시.. 2024. 3. 28. [오브젝트] 5장 - 책임 할당하기 내용 정리: 20240323 TIL, 20240324 TIL 1. 개요 5장에서는 책임 할당에 관한 다양한 기법들을 알아본다. 이전 장까지는 책임을 적절히 할당하는 것이 유연한 설계의 핵심임을 강조했다. 이제 그 책임을 어떻게 효과적으로 할당할 수 있는지 구체적인 방법들에 대해 알아볼 것이다. 책임 할당을 위한 가이드로 GRASP 패턴을 소개한다. 이 패턴들은 설계 과정에서 책임을 적절히 할당하는 데 도움을 줄 수 있는 가이드라인을 준다. 2. 책임 주도 설계 책임 주도 설계를 위해서는 설계 과정에서 데이터보다 객체의 행동에 초점을 맞춰야 한다. 객체가 수행해야 할 행동을 먼저 결정하고, 그 행동을 수행하는 데 필요한 데이터를 뒤이어 결정해야 한다. 객체가 수행해야 할 행동, 즉 책임은 협력에 적합해야 .. 2024. 3. 25. [오브젝트] 4장 - 설계 품질과 트레이드오프 내용 정리: 20240319 TIL 1. 개요 이번 장에서는 객체지향적이지 못한 설계가 초래하는 여러 문제점에 대해 살펴본다. 데이터 중심 설계를 직접 해보며 캡슐화, 응집도, 결합도의 관점에서 발생하는 문제점을 확인해 본다. 2. 접근자와 수정자 접근자와 수정자에 대한 의문 접근자(accessor)와 수정자(mutator)는 각각 클래스 내부 데이터를 반환하고 변경하는 역할을 한다. C++을 학습할 때 private으로 선언한 멤버 변수에 대한 접근자(getter)와 수정자(setter)의 필요성에 대한 의문을 가진 적이 있다. 왜 멤버 변수를 보호해야 한다면서 접근자와 수정자를 통해 외부에서 접근할 수 있게 할까? 당시에는 이 의문을 풀지 못하였고, 나 또한 접근자와 수정자를 많이 사용하며 코드를 작.. 2024. 3. 19. [오브젝트] 3장 - 역할, 책임, 협력 내용 정리: 20240311 TIL 1. 개요 3장은 역할, 책임, 협력에 초점을 맞춰 설명한다. 이전 장에서는 객체지향 프로그래밍의 다양한 기법들을 살펴봤지만, 이번 장에서는 그 기법을 넘어선 설계의 본질적인 요소에 대해 살펴본다. 아무리 효과적인 기법을 사용했다 하더라도 역할과 책임, 협력이 적절하지 못하다면 설계는 망가지게 된다. 2. 협력 협력(collaboration)은 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 의미한다. 객체들은 협력을 통해 메시지를 주고받으며, 메시지를 수신한 객체는 적절한 메서드를 실행하여 요청에 응답한다. 설계 관점에서 협력은 문맥(context)을 결정하는 중요한 요소다. 객체의 상태는 그 객체가 행동하는 데 필요한 정보에 의해 결정된다. 이 행동.. 2024. 3. 11. [오브젝트] 2장 - 객체지향 프로그래밍 내용 정리: 20240301 TIL, 20240302 TIL 1. 개요 2장은 객체지향 프로그래밍에 사용되는 다양한 요소에 대해 설명한다. 주요 키워드로는 "클래스, 캡슐화, 협력, 다형성, 상속" 정도가 있다. 2장은 1장보다 많은 내용이 등장해 정리하기 쉽지 않았다. 하지만 기존에 오해하고 있던 개념들을 바로 잡을 수 있었다. 2. 클래스 클래스에 대한 고정관념 객체지향 프로그래밍에 대해 생각할 때 대부분의 사람들은 '클래스'라는 단어를 먼저 떠올린다. 그만큼 우리는 알게 모르게 "객체지향 = 클래스"라는 고정된 사고방식을 가지고 있을지도 모른다. 실제로 많은 개발자들이 코드를 작성할 때, 먼저 클래스를 몇 개 생성하고 그 안에 어떤 속성과 메서드를 넣을지 고민한다. 나 역시 그동안 설계를 할 때 클.. 2024. 3. 4. [오브젝트] 1장 - 객체, 설계 내용 정리: https://github.com/wonyangs/TIL/blob/main/202402/20240222.md 1. 개요 오브젝트의 첫 장에서는 객체지향 프로그래밍이란 무엇이고 왜 필요한지를, 티켓 판매 시스템을 예로 들어 설명한다. 주요 키워드로는 "패러다임, 의존성, 결합도, 응집도, 캡슐화"가 언급된다. 처음부터 다소 많은 키워드가 한꺼번에 등장하는 것 같다는 느낌이 들었다. 하지만 저자는 그런 우려를 미리 예측한 듯, 서문에서 아래와 같이 언급한다. 1장 '객체, 설계'에서는 티켓 판매 시스템이라는 간단한 도메인을 예로 들어 책의 전체적인 주제를 함축해서 전달한다. 1장에서 소개하는 용어와 개념들이 이해되지 않더라도 너무 걱정하지 않았으면 한다. 이어지는 장들을 읽다 보면 자연스럽게 1.. 2024. 2. 22. 이전 1 2 다음
