Chapter 2 객체의 행동과 상태

[InHyeok-J]

56p

상태 캡슐화에서 객체의 상태를 캡슐화하고, 행동 만으로 협력에 참여한다고 한다.

근데 예시에서

이렇게 사람이 음료에게 마실게! 라는 메시지를 보내면 사람 입장에서는
수신자의 상태를 확인할 수 없는게 캡슐화의 본질이라고 하는데
what은 알고, how는 알지 못한다고 하더라고 what이 잘 처리 됐는지 송신자 입장에서 알지 못할 수 있지 않나?(void 형태라면)

[JoeSeongchan]

맞음. boolean 값을 리턴받아 잘 처리되었는지 여부를 확인할 수 있음.
아니면 해당 메소드가 실행이 잘 안 됐을 때 Exception을 던지도록 하여 what 처리 여부를 확인할 수 있음.

조성찬

[qudtjs0753]

그렇지요

void 반환값으로 지정하려 했을 때 exception으로 비즈니스 로직을 처리하는 것도 하나의 방법임은 분명.
하지만 exception의 처리 비용이 매우 비싼것도 고려를 해야할 듯 함.
관련 글

[InHyeok-J]

Java 언어가 예외를 던지는것에 대한 비용이 크다는 것은 동의합니다만 11년도 글이라서 살짝 신뢰성이 떨어지네요..
Exception의 비용은 예외를 캐싱하는 것으로 비용을 줄일 수 있다고 하네요 https://thswave.github.io/java/exception/2015/06/28/exceptions-are-bad.html

[qudtjs0753]

22년도 exception 성능 비교 글입니다!
https://www.baeldung.com/java-exceptions-performance
캐싱을 하지 않는다는 가정하에 비교한 글이라 논점과 조금 다를 수 있겠지만, 일반적인 처리와 성능차이가 난다는 것은 분명하다고 생각됩니다.
캐싱으로 비용을 줄일 수 있는 부분은 고무적이네요~

[InHyeok-J]

비용이 크긴 하네요 정상적인 플로우에서는 사용하지 말라고 명시까지 돼 있군요.
아직 매우 주니어 레벨이고, 제가 알고 있는 레벨에서는 네트워크나 DB의 영향이 메모리 최적화 영역보다는 훨씬 영향이 있는걸로 알고있어서 JVM 상에서 저렇게 최적화하는게 현시대의 시스템 속도 차원에 얼마나 영향을 미칠지 궁금하긴 합니다..
개인적인 의견입니다만 예외를 던지는 것이 아닌 에러 코드를 후 처리하는 로직(if else)이 비지니스 로직과 관련이 없다면 그 부분에서 개발자의 실수로 발전할 수 있는 사이드 이펙트도 있을거라고 생각이듭니다

[qudtjs0753]

네트워크, DB에서의 최척화가 훨씬 중요하다는 것에 동의합니다! exception에 관련된 비용에 대해 우선 어느정도 인지하고 있다는 것으로 충분하다고 생각이 되네요. if else와 exception 처리 중 어떤 것을 고르냐에 대해 다양한 측면에서 고려하자는 정도로 생각해보면 좋을 것 같아요