데브코스 프리팀과 즐거운 스터디 - 3주차

---

👥 프리팀 어벤져스

• 김민희, 문종운, 박이슬, 이근우, 황창현, 홍혁준(🙌)

🧑‍🏫 프리팀을 위해 시간 투자 해주시는 멘토님

• 네이비 멘토님(👍)

📔 스터디 주제

• 자바 플레이그라운드 with TDD, 클린 코드

플레이그라운드

---

😭 아쉬운 한 주

아쉽게도 해당 주에 일본여행(🇯🇵)을 가게 되어서 스터디 과제에 참여를 못하게 되었다. 하지만 팀원들의 코드와 리뷰를 보면서 어느정도 인지를 하고 글을 쓰게 되었다. 과제 참여는 못했지만, 코드 리뷰를 보니 점점 고민이 통일화되면서 질문이 줄어드는 모습을 보았는데, 이것은 역시 우리가 성장하고 있다는 것..?!이 아닐까? 계속해서 내 열정 불꽃은 타오른다! ♨️

---

1. 추상 클래스와 인터페이스를 사용해야하는 적절한 시기는 언제일까?

• 팀원들의 의문 : 'Default Method'가 인터페이스에 등장하게 되면서 추상 클래스의 특유 템플릿 메서드 패턴의 형식도 인터페이스에서 구현할 수 있게 되었다. 이런 관점에서 인터페이스를 사용할 수 있으니 추상 클래스를 사용할 필요가 있는 걸까..?
• 팀원들의 추상 클래스 사용 시기 의견 : 인터페이스에서 상태는 'static'으로 밖에 선언을 못하기 때문에, 안정성 측면에서 공통된 상태가 있을 때 추상 클래스를 사용해야 하지 않을까?

[블랙잭 게임으로 적절한 시기를 찾아보자.]

• 블랙잭 게임은 딜러와 게이머가 필요하다.
• 딜러와 게이머는 공통적으로 '카드를 뽑거나' , '카드의 점수를 계산하거나' , '카드를 뽑을 수 있는 조건인지에 대한 판단'을 할 것이다.
• 이때, 우리는 인터페이스를 사용해야 할까 ❓ -> 아니다❗️ 왜냐하면 'Player'로 추상화 시켜서 추상 클래스를 만들고 공통 기능을 구현하면 되고 딜러나 게이머에게 필요한 추가 기능들은 각 클래스에서 구현하면 되기 때문이다.

[그럼 인터페이스는 언제 필요할까?]

• 설계를 할 때, 블랙잭 게임에 대한 로그를 저장해야한다는 요구사항이 있다고 가정을 해보자.
• 처음에는 로그를 'MySQL'에 저장하라는 요구사항이었다.
• 하지만, 추후 모니터링을 위해 'ES'로 옮기라는 추가 요구사항이 나온다고도 가정을 해보자.
• 이럴 경우에는 동일한 요구조건(설계)에 대해서 다른 방식으로 구현을 해야하는 상황이 온 것이다.
• 즉, 인터페이스를 사용하지 않았다면, 많은 코드들에 수정이 생기지만, 인터페이스를 사용했다면 큰 문제 없이 'ES'로 옮겨갈 수 있을 것이다.

이처럼 멘토님은 블랙잭 게임을 예시처럼 인터페이스와 추상클래스를 나눠 사용한다고 한다. 
결론적으로 어떤 구현사항의 대한 클래스에서 좀 더 구체화된 확장이 필요하다면, 추상 클래스를 사용하고 동일한 요구조건(설계)에 대해 다른 방식으로 구현을 해야 한다면 인터페이스를 사용하면 될 것 같다.

---

2. 실무에서는 추상 클래스를 적절하게 사용하고 있을까? 혹은 인터페이스만 사용할까?

결론부터 말하면 멘토님은 실무에서 추상클래스를 잘 활용하고 계신다고 한다. 예를 들어 엔티티 구현 시, 공통 필드와 기능들이 있다면 템플릿 메소드 패턴을 사용해서 추상 클래스를 사용한다고 한다.

추가로, 인터페이스의 'Default Method'는 'abstract class'를 대체하기 위한 기능은 아니라고 말씀해주셨다.
'default method'는 태생이 람다를 위해 만들어진 것이고 상태도 가지지 못하기 때문에 용도가 제한적이라고 한다. 상태가 없는 템플릿 메소드 패턴 등을 사용할 때 인터페이스만 가지고 할 수 있긴 하지만, 멘토님은 모두 추상 클래스로 하신다고 한다!

---

데브코스 네이비 프리팀 화이팅❗️