필자는 실제 서비스 및 DAO 클래스와 동일한 인터페이스를 가진 몇 가지 봄 - 최대 절전 웹 응용 프로그램 프로젝트를 보거나 보았습니다.항상 서비스 및 DAO 레이어에 단일 구현 인터페이스가있는 이유는 무엇입니까?
나는 항상 생각하는이 하나의 구현 인터페이스를 가진 주요 원인으로 두 가지 :
봄이 지정된 클래스 (느슨한 결합)에 종속 등의 실제 구현을 연결할 수 있습니다
public class Person { @Autowired private Address address; @Autowired private AccountDetail accountDetail; public Person(Address address, AccountDetail accountDetail) { // constructor- 을
유닛 테스트 중에 mock 클래스를 만들고 클래스를 독립적으로 테스트 할 수 있습니다. EasyMock에 같은
public class Person { @Autowired private AddressImpl address; @Autowired private AccountDetailImpl accountDetail; public Person(AddressImpl address, AccountDetailImpl accountDetail) { // constructor모의 프레임 워크 구체적인 클래스뿐만 아니라
을 조롱 할 수 있습니다봄 종속성으로 구체적인 구현 클래스를 연결할 수 있습니다 :
Address mockedAddress = mock(Address); AccountDetail mockedAccountDetail = mock(AccountDetail); Person underTestPerson = new Person(mockedAddress, mockedAccountDetail); // unit test follows
는하지만, 늦게, 나는 것을 깨달았
AddressImpl mockedAddress = mock(AddressImpl);
AccountDetailImpl mockedAccountDetail = mock(AccountDetailImpl);
Person underTestPerson = new Person(mockedAddress, mockedAccountDetail);
// unit test follows
또한, this 논의에 따르면, 요약하면 단일 응용 프로그램 내에서 인터페이스가 협약이나 습관에서 대부분 과용됩니다. 일반적으로 전 세계 여러 응용 프로그램에서 사용되는 slf4j와 같은 다른 응용 프로그램과 인터페이스 할 때 가장 적합합니다. 단일 응용 프로그램 내에서 클래스는 인터페이스와 거의 동일한 추상화입니다.
내 질문에 우리는 여전히 인터페이스가 필요하고 * ServiceImpl 및 * DaoImpl 클래스와 같은 단일 구현을 갖고 불필요하게 코드 기반 크기를 늘리는 것입니다. 내가 알지 못하는 구체적인 수업을 조롱하는 데 문제가 있습니까?
언제든지 팀 동료와 이야기했지만, 인터페이스에 기반한 서비스 및 DAO 클래스를 구현하는 것은 모두가 따르는 디자인입니다. 스프링 권장 사항, OOP, DDD 등을 언급합니다.하지만 격리 된 응용 프로그램 내에서 너무 많은 인터페이스가있는 이유는 아직 실용적인 이유가 없습니다.
대답에 관해서는 - 나는 각 개체 앞에 인터페이스를 던지는 이유 때문에 DDD를 어떻게 호출 할 수 있는지 보지 못했습니다. DDD는 그 일과 관련이 없습니다. OOP조차도 열악한 근거가됩니다. L, I, D와 같은 것들을 SOLID와 같이 사용한다면 인터페이스와 같은 추상화를 어떻게 디자인해야 하는지를 지정합니다. * 항상 사용해야하는 것은 아닙니다. 당신이 말했던 것처럼 나는 그것이 모두 "봄 최고의 연습"에 버틸 수 있다고 생각하거나 습관적으로 그렇게하는 사람들입니다. – guillaume31