6장 메시지와 인터페이스

[lee-ji-hoon]

No description provided.

[audxo112]

디미터의 법칙
"오직 하나의 도트만 사용해라"

에서 MutableStateFlow 의 value 를 사용하는 것도

private val _data = MutableStateFlow("")
val dataValue
    get() = _data.value

이런 식으로 해야 할까

[ldh019]

@audxo112 오직 하나의 도트만 사용해라를 너무 과하게 생각하지 않아도 될거 같은게 뒷부분에도 나오지만 연산같은건 상관없다 라고 나오잖아
맥락적으로 봤을때 약간 객체의 객체의 객체 이런식으로 쓰지 말라는거 아닐까
value같이 그 객체가 고유하게 가지고 있는 값들 경우에는 우리 원래 쓰듯이 써도 되지 않을까?

[yangsooplus]

나도 동훈이 의견에 동의해 하나의 도트를 사용하라를 강박적으로 . 하나만 써라가 아니라
외부에서 내부 구현을 너무 파고들지 않게 조심하라 라는 의도를 받아들이는게 나을거같아
StateFlow의 value는 음.. 내부 구현이라고 할 수는 있지만 그 자체가 StateFlow의 사용법이니까 예측할 수 있는 영역이라고 생각해
특수케이스라고 보는게 맞다고 생각

[yangsooplus]

명령-쿼리 분리하는 부분이 평소에 내가 자주 간과하던 부분이라고 깨달았어

프로시저랑 함수를 분리해서 생각해본적이 없었다고 해야할까?
용어를 몰랐다는게 중요한 게 아니라 프로시저와 함수의 동작과 그 결과를 말이지

프로시저 procedure: 내부의 상태를 변경하는 루틴
- 부수효과 발생, 값 반환 불가
함수 function: 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴
- 값 반환, 부수효과 발생 불가

그동안 짠 코드에서 명령이랑 쿼리가 공존하는 함수가 많이 있었던 것 같은데... 극단적이지만 Event랑 Schedule 예시 보면서 가져올 수 있는 문제점을 눈으로 보고, 분리했을 때의 코드랑 비교해보니까 바로 와닿네

[lee-ji-hoon]

디미터 법칙

처음 읽었을 때는 명석이형이 처음에 적어둔 것처럼 나도 의문이 들었던게 있었어.

Stream 형태로 구현한 것들은 다 안전하지 않고 디미터 법칙을 어긴것인가?
라는 생각이였는데, 6장 후반부 보니까 아니였고, 단지 하나의 구현에서만 모든 것을 처리하면 상관이 없다. 라는 내용으로 이해가 되더라고

가장 마음에 들었던 내용

이번 장은 읽으면서 가장 마음에 들었던 내용이 절대적인 법칙은 없다. 소프트웨어 설계에 법칙이란 존재하지 않고, 원칙만 존재한다.

• 설계는 트레이드오프의 산물이다. -> 항상 두 개 이상의 것들을 저울질하는게 중요하다.
• 초보자들은 어쩔 수 없이 원칙을 맹신하게 되고, 서로 충돌하는 경우에도 원칙의 정당성을 부여하려고 한다.

BEEP을 만들때 우리가 MVVM을 사용하면서 DataBinding을 적용하고 있는데 UiState까지 넣을려고(베이직한 MVI개념) 하다보니 뭔가 서로 충돌이 나는데도 억지로 넣고 사용을 할려고 했던 것도 생각이 나서 이 내용들이 가장 기억에 남아