Closed anthologia closed 2 years ago
https://jjingho.tistory.com/10 자바 빈은 특정 형태의 클래스를 지칭하는 용어이고, property 규약이란 그 형태에 대한 몇 가지 약속을 의미합니다. Spring bean은 스프링에 등록해서 관리하는 (생성, 라이프 사이클, DI 등) 객체를 지칭하는 용어이고요. 용어 자체의 개념은 어렵지 않아서 Java빈 클래스를 왜 쓰는지 검색 해봤는데 깊이 있는 내용을 찾을 수가 없었습니다. 다음 세션 전까지 진득히 찾아보고 다시 답변 올리겠습니다... 지송!
@charlesuu 님이 말한 것처럼 Java bean은 그냥 규약입니다. 우리가 평상시에 사용하는 클래스들이 몇 가지 약속만 지키면 그게 바로 Java bean이에요.
Java Bean을 사용하는 이유는
라고 해요.
그러나 한 가지 의문점이 들었어요. 마틴 파울러의 소트웍스 앤솔로지에서는 "getter, setter를 사용하지 말자" 라고 말하기 때문인데요.
왜 그럴까? 그 이유를 생각해보니 알아낼 수 있었어요. getter와 setter는 사실 캡슐화를 깨기 때문이에요. 객체는 서로 메세지를 주고 받으며 협력하면서 그에 따른 결과를 얻어야 하는데요. getter, setter는 사실상 객체의 상태 값을 밖으로 꺼내서 외부에서 해당 값을 변경할 여지를 주기 때문이에요. 우리가 자바의 정석 7장 스터디 당시 캡슐화에 대해 다뤘던 예시 중에 나오기도 했으니까요. 또, Tell, Don't Ask 에 대해서 짧게 다루기도 했었죠.
그럼 Lombok을 통한 @Getter, @Setter 어노테이션을 사용하면 해당 문제를 해결할 수 있을까? 라는 생각이 들었는데요. 다시 고민해보니, 제 생각으로는 Lombok 역시 결과적으로는 getter, setter를 사용하기에 마틴 파울러의 말을 지킬 수 없다고 생각해요. (https://stackoverflow.com/questions/58467296/does-project-lombok-contradict-the-data-encapsulation-of-using-a-getter-and-sett)
그러나 stackoverflow 답변에서 마틴 파울러가 말한 이유에 대한 힌트를 얻게 되었어요. 답변자는 비즈니스 로직을 처리하지 않고, 그저 데이터 컨테이너 역할만 하는 객체라면, @getter, @setter를 사용하는 건 괜찮다고 했어요. 그에 반해, VO 혹은 도메인 객체에서 섣부르게 @setter를 사용하는 건 외부의 개입 때문에 객체의 상태 값이 변경되어 비즈니스 로직에 영향이 갈 수 있으므로 자제하라고 했어요.
이걸 잘 고민해보면, 마틴 파울러는 비즈니스 로직이 담긴 도메인과 같은 객체에서는 캡슐화, 객체지향을 위해 이를 지켜야 하지만, DTO나 Spring에서 프로세스 처리를 하는 @Controller, @Service 빈에서는 이를 엄격하게 지키지 않아도 된다고 말하는 것이 아닐까 싶어요. (https://limdingdong.tistory.com/15)
+) 우테코 블로그에서 비슷한 내용을 찾아서 추가해요. (https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/)
스스로 조금 찾아보고 코멘트 남기겠습니다. 이후에 이번 주차 리더 분께서 확인하신 후, 부족한 내용이 있으면 추가 부탁드려요.