[1장_양수진] Pull Request

src/main/kotlin/yangsooplus/ch01/Audience.kt

@@ -0,0 +1,9 @@
+package yangsooplus.ch01
+
+data class Audience(
+    val bag: Bag
+) {
+    fun buy(ticket: Ticket): Long {
+        return bag.hold(ticket)
+    }
+}

src/main/kotlin/yangsooplus/ch01/Bag.kt

@@ -0,0 +1,39 @@
+package yangsooplus.ch01
+
+data class Bag(
+    var amount: Long,
+    var invitation: Invitation?,
+    var ticket: Ticket?
+) {
+    constructor(amount: Long): this(amount, null, null) {
+        this.amount = amount
+    }
+
+    constructor(invitation: Invitation, ticket: Ticket): this(0L, invitation, ticket) {
+        this.invitation = invitation
+        this.ticket = ticket
+    }
+
+    fun hold(ticket: Ticket): Long {
+        this.ticket = ticket
+        return if (hasInvitation()) {
+            0L
+        } else {
+            minusAmount(ticket.fee)
+            ticket.fee
+        }
+    }
+
+    private fun hasInvitation() = invitation != null
+
+    fun hasTicket() = ticket != null
+
+
+    private fun minusAmount(amount: Long) {
+        this.amount -= amount
+    }
+
+    fun plusAmount(amount: Long) {
+        this.amount += amount
+    }
+}

src/main/kotlin/yangsooplus/ch01/Invitation.kt

@@ -0,0 +1,5 @@
+package yangsooplus.ch01
+
+import java.time.LocalDateTime
+
+data class Invitation(val date: LocalDateTime)

src/main/kotlin/yangsooplus/ch01/README.md

@@ -0,0 +1,41 @@
+## 첫번째 코드의 문제점
+
+1. 관람객과 판매원이 소극장의 통제를 받아 수동적으로 움직인다. Theater의 enter 메소드를 이해하기 위해서는 Audience-Bag, TicketSeller-TicketOffice 사이 관계와 그 내용을 알아야만 한다.
+2. 변경에 취약하다. Theater는 지나치게 세부적인 사실에 의존해 동작하고 있다. 세부 내용 중 하나라도 변경되면 Theater도 변경되어야 한다. 
+3. 책임이 Theater에 집중되어 있다.
+
+➡ 객체 사이의 결합도가 높아 생긴 문제이다.
+
+➡ 객체지향 설계 = 서로 의존하면서 협력하는 객체들의 공동체 구축
+
+➡ **최소한의 의존성을 유지하면서 불필요한 의존성을 제거하자!**
+
+## 어떻게 개선하지?
+
+- 구현과 인터페이스를 구분하고, 인터페이스에 의존하게 하자.
+  - 내부 구현은 노출하지 않은 채로 인터페이스만을 공개 
+  - 외부의 간섭을 배제하고 메세지를 통해서만 협력
+  - 자율성⬆, 결합도⬇, 응집도⬆
+
+- 응집도? (cohesion)
+  - 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 특성
+
+
+### 무.족.권 자율성이 높으면 좋은건가?
+
+- p.32~33에서 TicketSeller가 TicketOffice의 구현이 아닌 인터페이스에 의존하게 되면서 TicketOffice가 Audience에 관해 알게 되었다.
+- TicketOffice의 자율성은 높아졌지만, 전체 설계의 결합도가 상승했다.
+
+***줄건 줘!***
+
+- 어떤 기능을 설계하는 방법은 여러 개일 수 있고, 모든 사람들은 만족시킬수도 없다.
+- 트레이드오프!
+- 이번 경우에는 TicketOffice의 자율성을 높일 것인가, TicketOffice가 Audience를 알지 못하게 할 것인가 양자택일 해야한다
+
+
+### 좋은 설계란?
+
+- 기능 요구사항을 충족하는 동시에 변경에 열려 있는 설계
+- 요구사항이 항상 변경되기 때문에 변경 수용 능력이 중요하다!
+- 코드를 변경하면서 버그가 추가될 가능성도 줄여준다.
+- 변경 가능하다 = 이해하기 쉽다 (이해 못하면 변경하는거 개고생하잖슴~)

src/main/kotlin/yangsooplus/ch01/Theater.kt

@@ -0,0 +1,8 @@
+package yangsooplus.ch01
+
+data class Theater(val ticketSeller: TicketSeller) {
+
+    fun enter(audience: Audience) {
+        ticketSeller.sellTo(audience)
+    }
+}

src/main/kotlin/yangsooplus/ch01/Ticket.kt

@@ -0,0 +1,3 @@
+package yangsooplus.ch01
+
+data class Ticket(val fee: Long)

src/main/kotlin/yangsooplus/ch01/TicketOffice.kt

@@ -0,0 +1,23 @@
+package yangsooplus.ch01
+
+data class TicketOffice(
+    var amount: Long,
+    val tickets: MutableList<Ticket>
+) {
+
+// 티켓을 파는 행위를 TicketOffice 로 가져왔지만, Audience 에 대한 의존성이 생겨버린다!
+// 줄건 줘!!!
+//    fun sellTicketTo(audience: Audience) {
+//        plusAmount(audience.buy(getTicket()))
+//    }
+
+    fun getTicket(): Ticket = tickets.removeAt(0)
+
+    fun minusAmount(amount: Long) {
+        this.amount -= amount
+    }
+
+    fun plusAmount(amount: Long) {
+        this.amount += amount
+    }
+}

src/main/kotlin/yangsooplus/ch01/TicketSeller.kt

@@ -0,0 +1,10 @@
+package yangsooplus.ch01
+
+data class TicketSeller(
+    private val ticketOffice: TicketOffice
+) {
+
+    fun sellTo(audience: Audience) {
+        ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()))
+    }
+}