CHAPTER 2 객체지향 프로그래밍 패러다임

[yangsooplus]

잼있네요~ 오브젝트 읽으면서 봤던 내용들을 한 바닥에 돌아볼 수 있었던 장이었읍니다 실제 비즈니스 상황에서 있을만한 예시를 들어서 이해도 잘 되고, 실제로 사용하는 빈약한 도메인도 언급되기도 하니까 더 재밌었던 것 같읍니다

[lee-ji-hoon]

상속 대신 합성

새를 예시로 들었던 예시가 가장 인상 깊게 보였어 최근에 봤던 ViewHolder가 살짝 그런 유형이어서 디버깅하는데 살짝 난감하더라고 그래서 항상 상속보다는 합성을 먼저 생각하게 되는 거 같아. 상속을 잘못하면 걷잡을 수 없이 틀어지는 경험을 했는데, 합성으로 그 정도의 경험을 못해봐서 그런 걸 수도 있겠다

추상화된 공통 함수의 경우 구현 세부 사항을 노출을 시키면 안 된다.

난 이게 모듈 / 패키지 네이밍에도 동일하게 들어가야 한다고 생각해. 우리가 Network를 사용할 때 주로 Retrofit을 사용하지만 이전에는 Volley를 사용했던 것처럼 언제든 바뀔 수 있는데 얘의 패키지명을 retrofit이라고 해버린다면 패키지 네이밍 전체가 바뀌어야 하는 상황인데 network 라던지 공통화된 이름으로 해두면 나중에 바뀔 때도 내부 구현만 바뀌지 패키지명 같은 외부 요인은 바뀔 게 없어서 지금도 난 외부에 노출되는 곳에 내부 세부 사항은 노출 안 시키려고 해

상속대신 합성

합성하니까 생각나는 게 Compose에서 class로 안 하고 function으로 한 게 상속 대신 합성을 하기 위해서다.라는 내용을 비슷하게 책에서 본 거 같은데 선언형은 원래 함수로 이뤄지나?라는 생각도 드네

추가적으로 인터페이스를 정의할 때 클래스를 먼저 구현하고 그에 맞춰 인터페이스를 정의하는 경우가 적지 않고, 이 방법은 추상화가 충분히 이루어지지 않고 안 좋은 점이 되게 많은데 추상화를 먼저 하는 건 정말 어려운 거 같아. 어디까지가 공통적으로 사용이 될지, 이 인터페이스가 공통으로 사용이 될지 고민이 많이 되다 보니 그냥 구현해 두고 나중에 중복이 나오면 그때서야 인터페이스 화하는 거 같아 난

[ldh019]

객체지향 분석, 설계, 프로그래밍

내용에서도 말하다시피 자신만의 방법이 있는게 가장 좋다고 했지만, 내 입장에선 이런 대략적인 스케치를 해주는게 이해가 잘 되고 좋다고 느꼈어. 확실히 길을 깔아주니까 이렇게 하면 혼자서 해볼 수 있겠다 라는 생각이 드는 좋은 방법인거 같아~

빈약한 도메인 모델

보고 너무 충격받음. 헉 도메인을 저렇게 하는게 "빈약한" 도메인 모델이라니... 모델을 따로 만드는게 절차지향 이라는 생각을 한번도 안해봤는데 생각해보니 struct 랑 별반 다른게 없구나를 깨달았어.. 근데 또 저장소랑 컨트롤러 부분은 안 고쳐도 된다는게 나는 조금 의문...이 들다가도 어쩔 수 없이 바깥과 연결되어있으니 받아들여야 한다는게 조금 찝찝하달까.. ㅎㅎ

상속보다 합성

여러번 봤던 이야기이기도 하고, 내가 직접 구조를 만들때는 나도 상속보다는 합성이 익숙해진 터라 그냥 그러려니 하는데 막상 또 이전 책에서는 상속을 구조 구현을 위해 잘 쓰면 좋다~ 는 뉘앙스를 많이 들어서 "설계" 에 대한 경험을 한번 크게 해보면 좋을것 같다는 생각이 또 들기도 하네

상속 - 코드 재사용

오브젝트에서 1번 역할이 코드 재사용이 되면 안된다!!!! 라고 신신당부 하셨는데 자꾸 책에서 이런 얘기가 나오니까 "물론 그것도 할 수 있지~" 라고 생각하면서도 자꾸 찝찝해. 하지만 쟤도 충분히 중요한 역할이긴 하니까 적당히 받아들이는 연습을 해야할 것같아.. ㅋㅋㅋ