해결된 질문
작성
·
63
1
안녕하세요 🙂
5-4- 예제. 애플리케이션 객체 추가하기 강의내용 관련 질문이 있습니다. (DAO)
관련 예제 소스(https://github.com/eternity-oop/object-basic-05-04) 내에 보면 service 패키지에는 xxxDAO 인터페이스가 존재하고
persistence 패키지 내에는 xxxDAO 의 구현체 (xxxJbcDAO 클래스)들이 존재하는것을 확인하였는데요
이렇게 service 패키지 및 persistence 패키지 로 분리한것이
의존성을 제거하기 위함이라는 내용을 다른 질문내용으로 확인하였습니다 (https://www.inflearn.com/community/questions/1355997)
관련하여 이렇게 분리함으로써
service 패키지 내의 서비스 클래스는 DAO 의 역할만 확인하도록 하고 이에 대한 내부 구현은 신경안쓰겠다 라는것으로 이해하면 될까요 ? (역할 책임 분리)
답변 2
0
모아무개님 안녕하세요.
좋은 질문 주셔서 감사합니다. 🙂
정확하게는 인터페이스와 구현의 분리(separation of interface and implementation) 원칙에 해당되며 흔히 구현이 아닌 인터페이스에 대해 프로그램하라(program to an interface, not implementation)라는 가이드로 설명되고는 합니다.
예제에서 서비스가 DAO 구현 클래스가 아닌 인터페이스에 의존하는 이유는 불필요한 변경에 서비스 레이어가 영향을 받지 않게 만들고 싶기 때문입니다.
구현 방식과 독립적으로 인터페이스(역할의 개념으로 생각하셔도 됩니다)와 오퍼레이션(책임의 개념으로 생각하셔도 됩니다)을 정의하고 클라이언트가 인터페이스에 의존하도록 만들면 https://www.inflearn.com/community/questions/1355997에서 설명한 것처럼 구현을 교체하거나 구현의 변경에 영향을 받지 않도록 좀 더 안정적인 코드 구조를 설계할 수 있게 됩니다.
질문 주신 내용은 결합도와 캡슐화와 연관이 깊은데요
이 주제는 6-3. 결합도와 6-4. 캡슐화에서 자세히 다루고 있습니다.
답변이 되었는지 모르겠네요. 🙂
0
안녕하세요, 인프런 AI 인턴입니다. 모아무개님, 질문 남겨주셔서 감사합니다.
5-4- 예제에서의 DAO 패턴의 활용과 서비스 패키지와 퍼시스턴스 패키지의 분리에 대한 의문이 있으신 것 같습니다. 맞습니다. 서비스 패키지와 퍼시스턴스 패키지를 분리함으로써, 서비스 클래스는 DAO의 역할에만 의존하고, 그 내부 구현에는 신경 쓰지 않는 설계를 통해 의존성을 줄이는 것이 의도입니다.
핵심 개념 요약:
1. DAO 패턴: 데이터 접근 계층(Data Access Object)은 데이터베이스 상호작용을 캡슐화하는 역할을 합니다. 이를 통해 서비스 계층은 데이터 접근에 대한 구체적인 구현을 몰라도 됩니다.
역할과 책임의 분리(DIP 원칙): 서비스 클래스는 DAO 인터페이스에 의존하게 되어, 구체적인 구현체가 변경되더라도 서비스 계층에 영향이 가지 않도록 설계되었습니다. 이는 객체지향 설계 원칙 중 의존성 역전 원칙(Dependency Inversion Principle)을 적용한 예입니다.
유연성 극대화 및 테스트 용이성: 이 같은 구조는 다양한 데이터 접근 구현체를 사용하거나 테스트 시 목(Mock) 객체를 활용할 수 있는 유연성을 제공합니다.
관련하여 참고하실 만한 기존 질문이 있습니다. 예제의 설명에 도움을 줄 수 있으니 확인해 보시길 추천드립니다:
- DAO 관련 질문드립니다
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.