Skip to content

Commit 15f4797

Browse files
authored
Merge pull request #28 from lee-ji-hoon/ezhoon
[6장_이지훈]
2 parents 6b4a25e + b1d9f63 commit 15f4797

File tree

4 files changed

+116
-0
lines changed

4 files changed

+116
-0
lines changed
+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
package ezhoon.chapter06
2+
3+
import java.time.Duration
4+
import java.time.LocalDateTime
5+
6+
data class Event(
7+
private val subject: String,
8+
val from: LocalDateTime,
9+
val duration: Duration,
10+
) {
11+
12+
fun isSatisfied(schedule: RecurringSchedule): Boolean = !(from.dayOfWeek != schedule.dayOfWeek || from.toLocalTime() != schedule.from || duration != schedule.duration)
13+
14+
fun reschedule(schedule: RecurringSchedule): Event = copy(
15+
from = LocalDateTime.of(
16+
from.toLocalDate().plusDays(daysDistance(schedule)),
17+
schedule.from
18+
),
19+
duration = schedule.duration
20+
)
21+
22+
private fun daysDistance(schedule: RecurringSchedule): Long = (schedule.dayOfWeek.value - from.dayOfWeek.value).toLong()
23+
}
+49
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
# 메시지와 인터페이스
2+
3+
## 디미트의 법칙
4+
5+
> 캡슐화를 다른 관점에서 표현한 것이다.
6+
> 묻지 말고 시켜라.
7+
8+
- 절차지향과 다르게, 객체지향은 객체에게 행동을 지시한다.
9+
- 내부의 상태를 이용해 어떤 메시지를 보내는 행동이 외부에서 실행이 된다면 캡슐화를 제대로 못한 것이다.
10+
11+
## 원칙의 함정
12+
13+
> 절대적인 법칙은 없다.
14+
> 소프트웨어 설계에 법칙이란 존재하지 않고, 원칙만 존재한다.
15+
16+
- 설계는 트레이드오프의 산물이다.
17+
- 초보자는 원칙을 맹목적으로 추종하게되고, 서로 충돌하는 경우에도 원칙에 정당성을 부여하려고 한다.
18+
- 원칙이 현재 상황에 부적합하다고 판단이 되면 무시하자.
19+
- 부적합하다고 판단을 했다는 것 자체가 해당 원칙의 장단점을 충분히 이해했다고 봐도 무방하다.
20+
- 그렇기에 부적합하다고 판단이 된다면 무시하자.
21+
22+
### 디미터 법칙에 대해서 오해하지 말자.
23+
24+
> 디미터 법칙을 `하나의 도트만 사용하라` 라고도 요약되기도 한다.
25+
26+
```kotlin
27+
IntStream.of(1, 15, 20, 3, 9).filter { x: Int -> x > 10 }.distinct().count()
28+
```
29+
30+
그럼 위 코드는 위반한 것인가?
31+
32+
- 아니다. `IntStream` 이라는 동일한 클래스의 인스턴스를 반환한다.
33+
- 그렇기에 `IntStream` 하나로 결합이 돼있고, 내부 구현에서만 모든 것을 처리하기 때문이다.
34+
- 묻는 것도 없었고, 모든 것을 수행하라고 시킬 뿐이다. 그렇기에 디미터 법칙이 위반된 것이 아니다.
35+
36+
**그렇기에 하나 이상의 도트를 사용하는 모든 케이스가 디미터 법칙을 위반한 것은 아니다.**
37+
38+
### 디미터 법칙은 완벽한가?
39+
40+
> No이다.
41+
42+
- 객체에게 시키는 것이 항상 가능하지는 않다.
43+
- 어떤때에는 물어야하는 경우도생긴다.
44+
- 어떤 원칙이 적절한지 부적절한지 판단한 수 있는 안목을 길러야 한다.
45+
- 설계는 트레이드오프의 산물이다.
46+
47+
48+
49+
**소프트웨어 설계에 법칙이란 존재하지 않는다. `원칙`이 존재할 뿐이다.**
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
package ezhoon.chapter06
2+
3+
import java.time.DayOfWeek
4+
import java.time.Duration
5+
import java.time.LocalTime
6+
7+
class RecurringSchedule(
8+
private val subject: String,
9+
val dayOfWeek: DayOfWeek,
10+
val from: LocalTime,
11+
val duration: Duration
12+
)
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
package ezhoon.chapter06
2+
3+
import org.junit.jupiter.api.Assertions.*
4+
import org.junit.jupiter.api.DisplayName
5+
import org.junit.jupiter.api.Test
6+
import java.time.*
7+
8+
class EventTest {
9+
10+
@Test
11+
@DisplayName("반복일정 테스트 코드")
12+
fun recurringScheduleTest() {
13+
// given
14+
val schedule = RecurringSchedule(
15+
"회의",
16+
DayOfWeek.WEDNESDAY,
17+
LocalTime.of(10, 30),
18+
Duration.ofMinutes(30)
19+
)
20+
val meeting = Event(
21+
"회의",
22+
LocalDateTime.of(2019,5,8,10,30),
23+
Duration.ofMinutes(30)
24+
)
25+
// when -> 이 테코에는 여기 뭐 들어가야하지?
26+
27+
28+
// then
29+
assertTrue(meeting.isSatisfied(schedule))
30+
assertTrue(meeting.reschedule(schedule).duration == schedule.duration)
31+
}
32+
}

0 commit comments

Comments
 (0)