Order 인터페이스

아, 그냥 단순히 Order클래스 입니다. 기준이 있다면 배우고 싶어서요.
인터페이스는 확장성, 역할과 구현의 분리를 위해, 인데 확장이란게 또 어떻게 보면 대단히 많은 경우에 가능하고, 그래서 보통 Repository처럼 스토리 상 확장이 예정이 되어지거나 아예 확장해서 쓰는 용도로 설계한 게 아니면 보통 OrderImpl 처럼 이렇게 오직 하나만을 위한 구현체? 처럼 Impl을 붙여서 사용하지 않을까 했는데 Order는 그런 거 없이 그냥 바로 구현체여서..
그럼 정석은 Order 인터페이스까지 만들고 OrderImpl로 Impl을 붙여서 암묵적으로 약속된 Order의 구현체는 OrderImpl 딱 이거다, 이거 하나다 이렇게 하는 거고,

편의를 위해 바로 구현체로 만드셨다는거죠?

정석은 모든 인터페이스까지 다 만들고, 통상적으로 전체 인터페이스 중 구현체가 하나만 필요한 것은 Impl을 붙여 암묵적으로 이건 오직 이 인터페이스의 하나만 존재한다, 하는거고

코드 복잡도와 생산성을 위해서 바로 구현체를 만드는 경우가 있다는 거죠?

그 구현체를 바로 만드는 경우의 기준을 알고 싶은데, 이건 아무래도 경험이겠죠 그럼..?

그럼 아예 interface 패키지를 두어서 구현체 정의한 부분과 똑같이 패키지 트리? 를 똑같이 만들면 보기 편하지 않을까요?

수업에서 src였나 거기 하위로 member 패키지 만들고 member에 관한 인터페이스, 그것들에 대한 구현체 만들었는데,

src 아래에 interface 폴더와 implement폴더를 만들어서 똑같이 구조시키면 좋지 않을까요?

interface > member > member.interface

implement > member > member.implement

지극히 개인적인 학습과 실무 경험에 의한 답변이니 참고만 해주시면 감사하겠습니다.

결국 저희가 하는 일은 문제 해결이라고 생각합니다. 어떤 요구사항을 잘 해결하기 위해 결국 추상화, DDD, 계층형 아키텍처, 디자인 패턴 등을 사용하는 것이라 생각합니다. 그러한 관점에서 추상화를 할 것인지에 대한 선택은 추상화를 함으로써 내가 작게는 이 비즈니스적인 요구사항을 더 잘 구현해낼 수 있는 지를 먼저 따져봐야할 것 같습니다.

말씀하신 인터페이스로 다형성을 확보하는 코딩 방법도 적재적소가 있다고 생각합니다. 강의 자료에서와 같이 서비스나 특히 리포지토리처럼 사용하는 기술에 따라 구현체들을 유연하게 바꿀 수 있어야 하는 다형성이 필요한 상황이라면 인터페이스를 사용하는 것이 좋은 문제해결 방법이라고 생각합니다. 다만 현재 강의의 Order 클래스와 같은 객체들은 다형성이 필요할 일이 없습니다. 이러한 클래스에 인터페이스를 만들고 추상화를 적용하는 것은 과한 설계가 될 수 있고 불필요한 곳에 비용이 들어가게 될 수도 있다고 생각합니다. 제가 좋아하는 개발 원칙 중 YAGNI 라는 말이 있습니다. 간단하게 말하면 필요하다고 예상 되는 것을 미리 추가하지 말고, 진짜 필요할 때 추가하라는 말입니다. 저는 인터페이스를 둬 추상화하는 것은 필요할 때 하셔도 된다고 생각합니다.

마지막으로 패키지 구조에 대해서 질문해주셨습니다. 이 부분 또한 정답이 없는 부분이라고 생각합니다. 이 부분에 대해서는 직접 해당 패키지대로 먼저 해보시면서 장단점을 따져보시는 게 더 좋을 것 같습니다.