[SPRING] 스프링 및 인터페이스

스프링 및 인터페이스

Spring이 여러분의 코드에서 인터페이스를 사용하도록 장려하는 방법에 대해 전체적으로 읽었습니다. 나는 그것을 보지 않는다. 스프링 XML 구성에는 인터페이스에 대한 개념이 없다. Spring의 어떤 부분이 실제로 (docs가 아닌) 인터페이스를 사용하도록 장려 하는가?

해결법

1. ==============================

   1.클래스에 대한 인터페이스를 정의하면 종속성 주입에 도움이됩니다. Spring 설정 파일은 클래스 자체의 인터페이스에 대한 정보를 가지고 있지 않다.

   클래스에 대한 인터페이스를 정의하면 종속성 주입에 도움이됩니다. Spring 설정 파일은 클래스 자체의 인터페이스에 대한 정보를 가지고 있지 않다.

   그러나 "동등한"기능을 제공하는 다른 클래스를 삽입하려는 경우 인터페이스를 사용하면 실제로 도움이됩니다.

   예를 들어 웹 사이트의 콘텐츠를 분석하는 클래스가 있고이를 Spring에 주입한다고 가정 해 보겠습니다. 삽입하고있는 클래스가 실제 클래스가 무엇인지 알게되면, 그것을 바꾸기 위해 많은 코드를 다른 구체적인 클래스를 사용하도록 변경해야합니다. 그러나 분석기 인터페이스를 만든 경우 원래의 DefaultAnalyzer를 쉽게 삽입 할 수 있습니다. DummyAnalyzer 또는 PageByPageAnalyzer 또는 그 밖의 것과 같은 본질적으로 동일한 작업을 수행 할 수 있습니다. 그 중 하나를 사용하려면 클래스를 변경하는 코드를 거치지 않고 Spring 설정 파일에 삽입 할 클래스 이름을 변경하기 만하면됩니다.

   유용성을보기 시작한 지 반년이 지났습니다. 유용하게 끝나는 대부분의 것들 (엔터프라이즈 언어 에서처럼)과 마찬가지로, 프로젝트가 성장하기 시작한 다음에 조금 더 많은 일을함으로써 얼마나 많은 시간을 절약했는지를 발견 할 때까지 처음에는 무의미한 작업이 추가 된 것처럼 보입니다.

2. ==============================

   2.Dependency Inversion 원리는 이것을 잘 설명합니다. 특히, 그림 4.

   Dependency Inversion 원리는 이것을 잘 설명합니다. 특히, 그림 4.

   위의 링크에서 예제를 java로 번역 :

   public class Copy {
       private Keyboard keyboard = new Keyboard(); // concrete dependency
       private Printer printer = new Printer();    // concrete dependency
       public void copy() {
           for (int c = keyboard.read(); c != KeyBoard.EOF) {
               printer.print(c);
           }
       }
   }
   

   이제 의존성 반전과 함께 :

   public class Copy {
        private Reader reader; // any dependency satisfying the reader interface will work
        private Writer writer; // any dependency satisfying the writer interface will work
        public void copy() {
           for (int c = reader.read(); c != Reader.EOF) {
               writer.write(c);
           }
        }
        public Copy(Reader reader, Writer writer) {
            this.reader = reader;
            this.writer = writer;
        }
   }
   

   이제 복사 기능은 키보드에서 프린터로 복사하는 것 이상의 기능을 지원합니다.

   코드를 수정하지 않고도 모든 Reader에서 모든 Writer로 복사 할 수 있습니다.

   그리고 지금은 봄과 함께 :

   <bean id="copy" class="Copy">
       <constructor-arg ref="reader" />
       <constructor-arg ref="writer" />
   </bean>
   
   <bean id="reader" class="KeyboardReader" />
   <bean id="writer" class="PrinterWriter" />
   

   또는 아마도 :

   <bean id="reader" class="RemoteDeviceReader" />
   <bean id="writer" class="DatabaseWriter" />
   

3. ==============================

   3.대부분의 대답은 "구현을 쉽게 스왑 할 수있는"형식이지만, 대답이 잘못되었다고 생각하는 이유는 무엇입니까? 부품. 그 대답은 거의 확실하게 테스트 가능성이라고 생각합니다. Spring이나 다른 IOC 프레임 워크를 사용하는지 여부에 관계없이 Dependency Injection을 사용하면 코드를 더 쉽게 테스트 할 수 있습니다. PrinterWriter 라기보다는 Writer를 사용하는 경우 Unit 테스트에서 Writer 인터페이스를 모의 할 수 있으며 코드가 예상대로 호출되는지 확인할 수 있습니다. 클래스 구현에 직접 의존하는 경우 유일한 옵션은 프린터로 걸어 가서 확인하는 것입니다. 자동으로 수행되지는 않습니다. 또한, 클래스에 대한 호출 결과에 의지하여 모의 할 수 없으면 테스트에서 모든 코드 경로에 도달 할 수 없으므로 품질이 저하 될 수 있습니다 (잠재적으로) 간단히 말해서 객체를 분리해야합니다 응용 프로그램 논리에서 그래프 작성. 이렇게하면 코드를 더 쉽게 테스트 할 수 있습니다.

   대부분의 대답은 "구현을 쉽게 스왑 할 수있는"형식이지만, 대답이 잘못되었다고 생각하는 이유는 무엇입니까? 부품. 그 대답은 거의 확실하게 테스트 가능성이라고 생각합니다. Spring이나 다른 IOC 프레임 워크를 사용하는지 여부에 관계없이 Dependency Injection을 사용하면 코드를 더 쉽게 테스트 할 수 있습니다. PrinterWriter 라기보다는 Writer를 사용하는 경우 Unit 테스트에서 Writer 인터페이스를 모의 할 수 있으며 코드가 예상대로 호출되는지 확인할 수 있습니다. 클래스 구현에 직접 의존하는 경우 유일한 옵션은 프린터로 걸어 가서 확인하는 것입니다. 자동으로 수행되지는 않습니다. 또한, 클래스에 대한 호출 결과에 의지하여 모의 할 수 없으면 테스트에서 모든 코드 경로에 도달 할 수 없으므로 품질이 저하 될 수 있습니다 (잠재적으로) 간단히 말해서 객체를 분리해야합니다 응용 프로그램 논리에서 그래프 작성. 이렇게하면 코드를 더 쉽게 테스트 할 수 있습니다.

4. ==============================

   4.아무도 언급하지 않았지만 많은 경우에 인터페이스를 생성 할 필요가 없으므로 구현 클래스는 두 개 이상의 구현 클래스가 없기 때문에 신속하게 전환 될 수 있습니다.

   아무도 언급하지 않았지만 많은 경우에 인터페이스를 생성 할 필요가 없으므로 구현 클래스는 두 개 이상의 구현 클래스가 없기 때문에 신속하게 전환 될 수 있습니다.

   인터페이스가 필요없이 생성 될 때, 클래스는 쌍 (인터페이스와 구현)으로 생성되며, 불필요한 보일러 플레이트 인터페이스를 추가하고 잠재적 인 종속성 혼동을 유발할 수 있습니다. XML 구성 파일에서 구성 요소는 때로 인터페이스 및 때때로 구현에 의해 참조되기 때문입니다. 런타임시 아무런 결과가 없지만 코드 규칙과 관련하여 일관성이 없습니다.

5. ==============================

   5.Spring이 인터페이스 사용을 장려하는 방법을 문서에서 분명히 알 수 없을 수도 있습니다.

   Spring이 인터페이스 사용을 장려하는 방법을 문서에서 분명히 알 수 없을 수도 있습니다.

   다음은 몇 가지 예입니다.

   이것은 내가 개인적으로 경험 한 예입니다. 나는 거기에 훨씬 더있을 것이라고 확신합니다.

6. ==============================

   6.인터페이스에서 프록시를 생성하는 것은 쉽습니다.

   인터페이스에서 프록시를 생성하는 것은 쉽습니다.

   스프링 애플리케이션을 살펴보면 서비스 및 지속성 인터페이스가 표시됩니다. 스프링 이디엄은 확실히 인터페이스의 사용을 장려합니다. 그것보다 더 명시 적으로되지 않습니다.

7. ==============================

   7.인터페이스를 사용하지 않으면 자동 배선 실패의 위험이 있습니다. 때때로 Spring은 Bean에 대한 Proxy 클래스를 생성합니다. 이 Proxy 클래스는 서비스 구현의 하위 클래스는 아니지만 모든 인터페이스를 다시 구현합니다. Spring은이 Bean 인스턴스를 autowire하려고 시도하지만 Proxy 클래스는 Bean 클래스와 호환되지 않습니다. 따라서 Bean 클래스로 필드를 선언하면 "안전하지 않은 필드 할당"예외가 발생할 수 있습니다.

   인터페이스를 사용하지 않으면 자동 배선 실패의 위험이 있습니다. 때때로 Spring은 Bean에 대한 Proxy 클래스를 생성합니다. 이 Proxy 클래스는 서비스 구현의 하위 클래스는 아니지만 모든 인터페이스를 다시 구현합니다. Spring은이 Bean 인스턴스를 autowire하려고 시도하지만 Proxy 클래스는 Bean 클래스와 호환되지 않습니다. 따라서 Bean 클래스로 필드를 선언하면 "안전하지 않은 필드 할당"예외가 발생할 수 있습니다.

   Spring이 서비스를 프록시 할시기를 알 수 없으므로, 사용자가 이러한 놀라움으로부터 자신을 보호하기 위해 자동 선언 된 필드를 선언 할 때 인터페이스를 선언하고이 인터페이스를 사용하는 것이 가장 좋습니다.

8. ==============================

   8.Spring은 어디에서나 인터페이스를 사용하도록 강요하지 않으며 단지 좋은 습관입니다. 구체적인 클래스 대신 인터페이스 인 일부 속성을 가진 bean을 가지고 있다면, 같은 인터페이스를 구현하는 모형을 사용하여 특정 객체를 단순히 전환 할 수 있습니다. 이는 특정 테스트 케이스에 유용합니다.

   Spring은 어디에서나 인터페이스를 사용하도록 강요하지 않으며 단지 좋은 습관입니다. 구체적인 클래스 대신 인터페이스 인 일부 속성을 가진 bean을 가지고 있다면, 같은 인터페이스를 구현하는 모형을 사용하여 특정 객체를 단순히 전환 할 수 있습니다. 이는 특정 테스트 케이스에 유용합니다.

   예를 들어 Hibernate 지원 clases를 사용한다면, DAO를위한 인터페이스를 정의한 다음 그것을 별도로 구현할 수 있습니다. 인터페이스를 갖는 이점은 Spring 인터셉터를 사용하여 인터페이스를 구성 할 수 있다는 것입니다. 이렇게하면 코드를 단순화 할 수 있습니다. 당신은 HibernateExceptions을 다루는 코드를 작성하지 않고 마지막 세션에서 세션을 닫을 필요가 없으며, 프로그래밍 방식으로 트랜잭션을 정의 할 필요가 없으며 Spring을 사용하여 선언적으로 모든 것을 구성합니다.

   빠르고 더러운 응용 프로그램을 작성할 때 JDBC 또는 최종 버전에서 사용하지 않을 간단한 프레임 워크를 사용하여 간단한 DAO를 구현할 수 있습니다. 몇 가지 공통 인터페이스를 구현하는 경우 해당 구성 요소를 쉽게 전환 할 수 있습니다.

9. ==============================

   9.별도의 인터페이스를 작성하면 일반적으로 불필요한 복잡성과 보편적 인 코드가 추가됩니다. 또한 IDE에서 메서드 호출을 클릭하면 구현 대신 인터페이스가 표시되므로 디버깅이 어려워집니다. 런타임에 구현을 바꾸지 않는다면, 그 길을 갈 필요가 없습니다.

   별도의 인터페이스를 작성하면 일반적으로 불필요한 복잡성과 보편적 인 코드가 추가됩니다. 또한 IDE에서 메서드 호출을 클릭하면 구현 대신 인터페이스가 표시되므로 디버깅이 어려워집니다. 런타임에 구현을 바꾸지 않는다면, 그 길을 갈 필요가 없습니다.

   Mockito와 같은 도구를 사용하면 인터페이스를 쌓지 않고도 종속성 삽입을 사용하여 코드를 쉽게 테스트 할 수 있습니다.

from https://stackoverflow.com/questions/256255/spring-and-interfaces by cc-by-sa and MIT license