[책너두 4기] 개발 서적 스터디 - 오브젝트 chapter 1 ~ 2장 요약

함께 자라기 책 저자가 작성한 블로그 글에 "바쁜 직장인을 위한 스터디 비결"이란 글이 있었다. 

지금은 이글루스라는 블로그 서비스가 종료하면서 볼 수가 없다. (https://www.codesoom.com/how-to-read-three-color-pen)

 

블로그 내용을 요약하면 매일 단시간 집중해서 핵심만 뽑아서 효율적으로 스터디 방법에 대한 소개글이다. 

 

[스터디 방법]

1. 25분 Timer 설정해서 정해진 분량을 다같이 읽는다.
2. 읽으면서 ‘가장 중요한 핵심’에만 빨간색으로 밑줄, 다음 중요 파란줄, 흥미로운 부분 초록줄
3. 다 못 읽었으면 5분 단위 타이머 추가
4. 다 읽었으면 20분 동안 밑줄 내용 + 밑줄 친 이유 공유
5. 휴식 (10분)

경험했던 개발 서적 스터디 중에 유일하게 탈주자 없이 완독한 방식이다.

 

이와 비슷한 효과를 하는 온라인 스터디가 있다. 

https://breakbook.oopy.io 

책너두 - 두달 간의 독서 챌린지

2달 동안 매일 정해진 분량을 읽고 요약본을 공유하는 활동이다. 

 

비대면이고,

하루 1시간 정도만 투자하고,

요약본이 카카오 오픈채팅으로 올라와서 반복적인 input이 좋았다.

 

주 1회 간격으로 내가 요약했던 내용을 올려본다.

 

읽는 책 : 오브젝트 (https://www.yes24.com/Product/Goods/74219491)

 

yes24

전반적인 내용

객체지향을 동작하는 코드를 기반으로 설명하는 책이다.

객체지향 코드 작성 방법보다 객체지향으로 얻는 좋은 설계에 초점을 둔다.

객체지향의 핵심이 무엇인가를 시작으로 좋은 설계에 대한 책.

 

프로그램 패러다임이란? 왜 필요할까?

• 패러다임이란? 한 시대 사회 전체가 공유하는 이론, 방법, 문제의식 등의 체계이다.
• 왜 필요할까? 패러다임을 공유하면 개발자 끼리 동일 규칙으로 코딩 → 불필요 의사소통 줄인다. 동일 문제 접근 방식, 동일 규칙

• 다양한 패러다임이 있다. (절차형, 함수형, 객체지향 . . .)
• 은총알은 없다. 패러다임은 공존하고 발전적인 것을 명심하자

 

[1일차]

Chapter 1. 객체, 설계 (1)

• 티켓 판매 소극장 애플리케이션 구현 (https://github.com/sendkite/oop)
  • 소극장을 객체로 설계해서 구현한 애플리케이션
  • 예제 문제점
    • 객체의 동작이 일반 상식을 벗어나서 이해하기 힘들다.
    • 결합도가 높아서 변경이 어렵다. (너무 많은 의존성)

맘에 드는 구절

• 소프트웨어 모듈은 3가지 목적 (feat. 로버트 마틴 - 클린 소프트웨어)
  • 실행 중에 제대로 동작
  • 변경을 위해 존재
  • 코드 읽는 사람과 의사소통

 

[2일차]

Chapter 1. 객체, 설계 (2)

• 티켓 판매 소극장 애플리케이션 개선 (https://github.com/sendkite/oop)
  • 소극장을 객체로 설계해서 구현한 애플리케이션
  • 아래 예제 문제점을 개선한다.
    • 객체의 동작이 일반 상식을 벗어나서 이해하기 힘들다.
    • 결합도가 높아서 변경이 어렵다. (너무 많은 의존성)
  • 정보 은닉 (캡슐화) 로 문제점을 개선한다.
    • Theater → 입장만 담당 (enter(audience))
    • TicketSeller → 티켓 판매만 담당 (sellTo(audience) 메서드 )
    • Audience → 티켓 구매만 담당 (buy(ticket) 메서드)
  • 개선 결과
    • 이해하기 쉽다. 객체가 일반 상식으로 동작한다.
      • Theater → 입장 책입
      • TicketSeller → 판매 책임
      • Audience → 구매 책임
    • 내부 코드 몰라도 메서드 이름만 읽어도 이해되는 코드가 되었다.
    • 변경이 쉬워졌다. 코드들이 적절히 이동하면서 (책임의 이동) 의존성이 사라졌다.

절차지향과 객체지향

• 절차지향에서 코드 판단해서 처리하는 로직을 프로세스라 표현한다.
• 프로세스가 위치한 곳에서 Audience, TicketSeller, TicketOffice, Bag, Ticket을 불러와서 처리하는 방식이 절차지향
• 객체 지향은 데이터를 불러오는게 아니라 데이터가 있는 곳으로 적절한 프로세스 단계를 분배하는 것을 말한다.

더 개선 해보자

개선 내용

• Theater → 입장 책입
• TicketSeller → 판매 책임 TicketOffice에게 구매자 구입 알림
• Audience → 구매 책임
• Bag → 초대장 판단해서 돈 -해서 티켓 살지 판단
• TicketOffice → 티켓 판매 책임

개선 결과

• TicketOffice에 의도치 않은 Audience 의존성이 생겼다.
• 즉 결합도가 높아졌다. 좋은 설계일까?
• 어떤 기능을 설계하는 것은 한가지 이상의 방법으로 설계할 수 있다.
• 설계는 Trade off 균형이다.

맘에 들었던 구절

캡슐화로 메세지(메서드 이름, 책임)만 읽고 코드를 이해하기 쉬워졌다. 근데 이제 의존성도 낮아져서 결합도가 낮고 응집도는 높아져서 변경이 쉽다.

• Theater → 입장 책임
• TicketSeller → 티켓 판매 책임
• Audience → 티켓 구매 책임

[3일차]

Chapter 1. 객체, 설계 (3)

• 티켓 판매 소극장 애플리케이션 개선 (https://github.com/sendkite/oop)
  • 소극장을 객체로 설계해서 구현한 애플리케이션
• 객체지향에서는 무생물도 자율적인 객체로 행동한다 == 의인화

설계란? 객체지향 설계?

• 설계란? 코드를 배치하는 것
• 좋은 설계란? 요구사항 변경에도 버그 없이 수정이 쉬운 설계
• 객체지향 설계란? 의존성을 효율적으로 통제하는 방법을 제공하여 변경이 쉬운 설계. 그리고 이해하기 쉬운 코드

Chapter 2. 객체지향 프로그래밍 (1)

• 온라인 영화 예매 시스템 구축 (https://github.com/sendkite/oop)
  • 시간대별로 가격 조건, 가격 정책을 달리할 수 있는 영화 예매 시스템
  • 이번 장은 예매 시스템을 객체지향 프로그래밍으로 구현

협력, 객체, 클래스

• 요구사항 분석하고 객체지향 프로그램 작성시 가장 먼저 무엇을 고민해야할까?
  • 객체 부터 생각한다. 객체 윤곽이 잡히면 공통 상태와 행위로 타입 정의하고 이를 기반으로 클래스 작성한다.
    • 클래스가 아니라 어떤 객체가 필요한지 고민한다.
    • 객체는 협력하는 공동체의 일원이다.
• 도메인
  • 도메인이란? 사용자가 문제를 해결하기 위해 프로그램 사용 분야
  • ex. 오프라인 예매 간소화 → 예매 도메인
• 클래스
  • 도메인 구조를 반영해 만든다.
  • 클래스의 경계를 구분한다,
    • public, protected, private 같은 접근 수정자를 활용해 감출 부분과 공개할 부분을 구분
    • 이렇게 하면 개발자가 내부 구현 무시하고 공개한 인터페이스만 보고 클래스 활용 가능
      • 더 적은 지식의 양으로 클래스를 활용해서 구현과 변경이 가능
      • 변경할 부분이 정해져 있어서 변경이 쉬움
• 객체와 협력
  • 상속과 다형성을 이용하면 객체에게 메시지 전달, 전달받은 메시지 처리(메서드)를 스스로 결정하게 만들 수 있다.
    • ex) Movie 가격 정책에 따라 알맞는 정책을 스스로 판단

맘에 들었던 구절

추상화라는 원리를 기반으로 상속, 다형성을 이용하면 금액 조건, 정책을 객체 스스로 판단하게 할 수 있다.

 

[4일차]

Chapter 2. 객체지향 프로그래밍 (2)

• 온라인 영화 예매 시스템 구축 (https://github.com/sendkite/oop)
• 이번 챕터 예제 내용
  • Movie에 추상 클래스인 DiscountPolicy를 의존하게 한다
  • DiscountPolicy를 상속, 메서드 오버라이딩하는 3개의 자식 클래스가 있다.
  • DiscountPolicy에는 N개의 DiscountCondition 객체를 파라미터로 받아서 할인가격을 책정하는 calculateDiscountAmount 메서드가 있다.
  • DiscountCondition은 인터페이스이고 할인 조건 만족 판단하는 isSatisfiedBy 메서드 선언
  • DiscountCondition 구현은 PeriodCondition, AmountCondition이 수행

할인 요금 구하기

• 할인 요금 계산을 위한 협력
  • 상속과 다형성을 이용하면 객체에게 메시지 전달, 전달받은 메시지 처리(메서드)를 스스로 결정하게 만들 수 있다.
    • ex) Movie 가격 정책에 따라 알맞는 정책을 스스로 판단
• Movie는 어떻게 N개의 DiscountPolicy, N개의 DiscountCondition을 적용 가능한지 판단해서 가격을 계산 할 수 있을까?
  • 코드의 Complie 의존성과 Runtime 의존성은 다르다.
  • Runtime에서 Movie에 인스턴스를 전달해서 어떤 가격 정책, 가격 조건을 적용할 것인지 판단 할 수 있다.
• Complie 의존성과 Runtime 의존성이 다르면 유연하고 확장 가능한 코드가 될 수 있다.
• 그러나 Compile 의존성과 Runtime 의존성이 다르면 코드 가독성이 떨어지고 디버깅이 어려워진다.
• 추상화는 Trade off 사이 균형이 필요

차이에 의한 프로그래밍

• 부모 클래스와 다른 부분만 추가해서 새로운 클래스를 빠르게 만드는 방법을 말한다.

상속과 인터페이스

• 상속이 가치있는 이유? 부모 클래스의 모든 인터페이스를 자식 클래스가 물려 받을 수 있다.
• 객체 입장에서 누가 메시지를 보내는 지는 중요하지 않다.
• Movie 입장에서 메시지를 수신 할 수 있다면
  • discountPolicy.calculateDiscountAmount(screening)를 수신할 수 있다면
  • discountPolicy가 어떤 클래스 인지는 중요하지 않다.
  • 부모에 로직이 있고 처리를 자식에게 위임하는 이 패턴을 템플릿 메서드 패턴이라 한다.
• N개의 자식 클래스가 1개의 부모 클래스를 대신 하는 것을 업캐스팅이라 한다.

다형성

• 동일 메시지를 수신 했을때 객체 타입에 따라서 다르게 응답되는 것을 다형성이라 한다.
• 다형성 구현 방법으로 Compile 시점이 아니라 Runtime 시점에 실행될 메서드가 결정되는 방법을 따르는데 이를 Lazy Binding, Dynamic Binding이라 한다.
• 상속을 이용하면 동일 인터페이스를 가지는 N개의 클래스를 1개의 타입 계층으로 묶을 수 있다.
• 다형성에 상속이 활용되는 것. 협력이 다형적이라 할 수 있다.
• 다형성을 구현하는 방법은 여러가지가 있다.

인터페이스와 다형성

• 구현은 공유할 필요가 없고, 순수하게 인터페이스만 공유하고 싶을때 인터페이스를 사용한다.
• 이 경우도 업캐스팅이 적용되며 협력은 다형적이다.
• 구현 상속을 서브클래싱이라 하고, 인터페이스 상속을 서브타이핑이라 한다.
• 상속은 구현 목적이 아니라 인터페이스 재사용 목적으로 사용해야 확장에 열려있다.

[5일차]

Chapter 2. 객체지향 프로그래밍

추상화와 유연성

• 추상화의 힘
  • 추상화를 사용하면 세부적인 내용을 무시한 채 쉽고 간단하게 표현할 수 있다.
• 유연한 설계
  • 구체적인 상황에 결합하지 않아서 유연하게 변경 가능
  • 컨텍스트 독립성이라 한다.
• 추상 클래스와 인터페이스 트레이드 오프
  • 구현과 관련된 모든 것들은 trade off 대상이다.

상속의 문제점 (추상클래스)

• 캡슐화 위반
  • 상속을 사용하기 위해 부모 클래스 내부를 알아야한다.
• 설계가 유연하지 못하다
  • 부모 - 자식 클래스 관계가 런타임이 아니라 컴파일 시점에 결정된다.
  • 변경이 유연하지 못하다.

합성 (인터페이스)

• 인터페이스를 사용하면 상속의 2가지 문제점을 해결한다.
  • 인터페이스는 메시지만 전달하고 구현은 구현체가 구현하기 때문에 느슨한 결합도를 가진다.
• 코드를 재사용하는 경우 합성을 선호하는 것이 옳다.
• 그러나 인터페이스를 재사용하는 경우 상속과 합성을 함께 조합해서 사용해야한다.

Chapter 3. 역할, 책임, 협력 (1)

• 객체지향 핵심은 역할, 책임, 협력이다.
• 클래스도 상속도 구현하는 방식일 뿐 더 중요한 것은 협력, 책임, 역할이다.

협력

• 어떤 객체가 다른 객체에게 무엇인가 요청하는 것
• 협력은 객체를 설계하는데 문맥을 제공한다.
  • ex) Movie를 일반적으로 생각했을때 영화 play, 극장안에 사람들을 상상한다. 하지만 예제에서는 Movie가 입장시 가격 계산을 수행한다 왜 일까?
  • “영화 예매하기 위한 협력”하기 위해 생성한 객체이기 때문이다.
  • 협력이 객체의 행동을 결정한다.
  • 행동에 필요한 값이 객체의 상태를 결정한다.
• 객체란? 상태와 행동을 캡슐화 한 실행 단위