해결된 질문
24.07.17 19:03 작성
·
124
0
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.
1. 강의 내용과 관련된 질문을 남겨주세요.
2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.
(자주 하는 질문 링크: https://bit.ly/3fX6ygx)
3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.
(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)
질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.
=========================================
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예/아니오)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)
[질문 내용]
여기에 질문 내용을 남겨주세요.
@Override
public Member save(Member member) {
String sql = "insert into member(member_id, money) values(?,?)";
template.update(sql,member.getMemberId(),member.getMoney());
return member;
}
@Override
public void update(String memberId, int money){
String sql = "update member set money = ? where member_id=?";
template.update(sql, money, memberId);
}
위에 2개가 강의 내용인데, update()도 초반 코드설계를
@Override
public Member findById(Member member){
String sql = "select * from member where member_id = ?";
return template.queryForObject(sql,memberRowMapper(),member.getMemberId());
}
이런식으로 Member를 받아와서 설계하는건 좋지않은방법인가요 ? 어차피 필요한건 member 객체 전체가 아니라 member_id하나만 필요하기때문에 ? 강의를 들을때는 이런식으로 설계하면 되는구나 하고 이해는 가는데 혼자서 메서드 설계할때 어떤식으로 접근해서 설계하는게 이상적인지 아직 어렵네요
답변 1
1
안녕하세요. deoksam님, 공식 서포터즈 OMG입니다.
질문 남겨주신 코드를 보니 @Override가 포함된걸로 보아 인터페이스로 정의된 클래스를 구현한 메서드 관련 코드인 것 같네요 😀
이 부분에 대한 기준을 정하려면 인터페이스 추상화에 대한 비용을 이해해야합니다.(인터페이스-구체클래스 관계가 아니여도 마찬가지입니다.)
아래 링크를 통해 추상화 비용에 대한 개념을 익히신 다음 다시 답변을 확인해주세요.
https://www.inflearn.com/questions/779605
제가 위 영한님 답변을 통해 말씀드리고 싶은 것은 두 가지 입니다.
1.코드가 복잡해진다.
2.유지보수가 어려워진다.
파라미터가 String 타입의 memberId하나라면 메서드를 호출하는 곳에서 넘겨 받는 인자가 String 타입의 id 하나이고, 이것은 객체를 인자로 받을 때와는 복잡도가 낮고, 가져온 데이터가 제한적이니 상대적으로 코드 확인이 쉬울 수 밖에 없습니다. 이는 유지보수와 연관이 되겠죠 ?
물론 이 관점에서만 본다면 무조건 단일 타입의 String으로 메서드 시그니처를 정의하는게 좋아보일 수 있는데요, 이것은 경우에 따라 다릅니다.
만약 해당 인터페이스가 다양한 구현체 클래스를 가지고 findById메서드를 호출하지만, 각 구현체에서 반드시 String 타입의 id만 필요할 것이라고 볼 순 없습니다.
회원 id뿐만 아니라 회원의 기타 정보까지 같이 필요한 경우라면 (메서드는 findById이긴하지만) 메서드의 시그니처는 변경이 되어야합니다.
이렇게 인터페이스를 구현하는 클래스들의 다양한 니즈를 만족해야하는 상황을 고려해야하는게 추상화에 대한 비용이며 이러한 점을 고려해야합니다.
결론적으로 제가 제안 드리는 기준은 다음과 같습니다.
인터페이스로 추상화된 상황의 메서드가 아니라면, 그리고 확장 가능성이 없고 구조가 단순해서 단일 파라미터로 끝나는 메서드이면 필요한 정보만을 메서드 시그니처에 정의합니다.
그 외의 상황은 위에서 말씀드린 상황(확장 가능성, 유지보수성, 코드 복잡도 등)을 고려하여 메서드 시그니처를 고려하면 될 것 같습니다.
답변을 드리다보니 개발 원칙 중 YAGNI 원칙과도 비슷한 내용으로 설명을 드린 것 같아 관련 개념도 배경지식으로 알아두시면 좋을 것 같아 소개드려요^^
감사합니다.
2024. 07. 18. 20:23
답변 감사합니다 !