객체 구조를 어떻게 설정할까?
일단 인터페이스의 존재 이유를 깨닫자.
정보처리기사 출처 - 인터페이스란, 두 어플리케이션 간의 상호작용을 위한 중간다리 역할.
그렇다면 우리는 이 interface를 활용해서, 각 객체간의 의존성 관계를 줄여야 한다.
ex) 카드사의 결제 구조를 생각한다면,
service에 각 카드별 find 등을 구현한다면 최종 paycontroller에서는 수많은 객체들(삼성,bc카드)등과 다 의존되어야 한다.
그렇다면, 신한카드, 우리카드 등에 따라 다른 service를 구현해야할때, 이 모든 것을
interface로 묶어, 이 interface를 controller에서 의존받아서 사용하는 방식이 내부 정보를 가리고,
의존성을 감소시키는 데에 큰 도움이 된다.
1. 객체의 크기
findby id, findbyemail,changepw,updatename등을 모두 service interface로 구현했다고 가정해보자 .
문제 1) findby id와 email은 , 결론적으로 동일한 기능이다.
2) change pw는 비밀번호 변경, 인증번호 보내기 등등 , interface로 취급하는게 좋을 수가 있다.
3) updatename은, 그떄그때 다르다.
4) service에서 하는 역할이 너무 많다.
5) fidnby는, interface로 구현할 필요가 없다. -> changepw는, 여러기능을 진행하기 때문에, interface로 구현하는 것이 현명한 방식일 수 있다.
CRUD에서, 조회끼리, UPDATE끼리, DELETE간의 다른 SERVICE객체를 사용하는 방식이
수많은 객체들을 처리해야할때는 옳은 방식 일 수 있다.
2. 객체의 협력 관계
EX) 주문 신청시 , 메세지 FLATFORM을 여러가지(SMS,KAKAOTALK)등이 있고, 이가 추가될 수 있을때
어떤 방식으로 객체를 리팩토링 가능할까?
내가 코드를 작성하다보면, 테스트코드 작성 과정에서 바로바로 문제가 나타난다.
(원하는 목표를 코드로 작성하기가 힘들거나.. 등)
그 과정에서 class의 별도 생성, 혹은 enum type추가 등을 진행한다.
3. 객체에게 질문 해서 안된다.
(정보를 꼬치꼬치 물어서는 안된다!) -> 무슨 의미인지는 코드를 보면서 맞추어보자.
EX)주문을 진행한다. 그 주문 과정에서 쿠폰이 있는지,
쿠폰의 상태가 만료인지, 사용가능인지, 몇%인지를
주문 진행 service에서 진행한다?
이는 문제가 있다. 주문의 역할을 해야할 주문 service에,
if (coupon.isused())등을 다 확인해야 하는 문제가 있다.
이렇게 진행하다보면, 쿠폰이 여러가지 변경이 생기거나, 쿠폰의 종류가 늘어나는 등.
쿠폰이 변경 되었는데 주문이 이를 책임져야하는 잘못이 발생한다.
이후 결제 method에서는, 이와 같이 coupon에 날짜만을 대입하게끔, 각 객체에서 역할이 치우쳐지지 않게 관리하자