가장 많이 사용하는 곳이 템플릿 방식(Template Method)을 구현하는 곳이죠? 예를 들어 원격 서비스를 위한 로컬 프록시 배치를 작성하려고 합니다. 이 에이전트 배치의 경우 요청 주소 획득, 요청 전송 및 해당 콘텐츠 획득 단계가 모두 공통적입니다. 문자 인코딩 유형을 정의하는 단계와 응답 콜백을 정의하는 두 단계만 다릅니다.
이때 추상 클래스를 정의하고 요청 프로세스를 완료할 수 있습니다. 차이점은 정의할 실제 하위 클래스에 맡겨집니다. 디자이너가 추상 클래스의 인스턴스화를 [허용하지 않는] 것이 아니라 원격 서비스의 특성을 알기 전에 일부 특성을 결정할 수 없어 인스턴스화가 불가능하다는 것입니다.
JDK의 예는 java.io.InputStream입니다. read(byte[], int, int) 메소드는 java.io.InputStream.read() 메소드를 호출합니다. Read()는 추상 메서드이므로 하위 클래스에서 정의해야 합니다. 소스코드를 통해 학습할 수 있습니다.
추상 메소드가 없는 추상 클래스가 특별한 의미를 갖는 것은 아닙니다. 이는 단지 추상 클래스의 일반적인 의미일 뿐입니다. 기본 구현을 고려하면 인터페이스를 직접 구현하는 것보다 코드가 덜 필요할 수 있습니다. 반면에 추상 클래스에 하나 또는 두 개의 추상 메소드를 유지하도록 요구하는 이유는 무엇입니까?
반대로 이 클래스의 하위 클래스가 특정 메소드를 생성하기 위해서는 . 물론 이것도 인터페이스의 요구 사항이지만 인터페이스에서는 모든 메서드가 추상 메서드여야 합니다. 그러나 추상 클래스는 하위 클래스에 의해 재정의될 필요가 없는 일부 메서드를 미리 정의할 수 있습니다.
추상 클래스와 인터페이스는 모두 추상화를 위한 것입니다. 추상화의 이점에 대해서는 언급하지 않겠습니다. 예를 들어 Equal 인터페이스나 클래스를 구현하려면 equal 및 unequal 두 가지 메서드를 정의합니다. 인터페이스를 사용하여 구현된 경우 클래스는 이 두 가지 메서드를 구현해야 합니다. 그러나 추상 클래스로 구현한다면 unequal은 추상 클래스에서 !equal처럼 구현될 수 있으므로 unequal는 그 하위 클래스에 구현되어야 한다.
개인적으로는 추상 클래스를 선호합니다(단, Java는 다중 상속을 지원하지 않습니다). 예를 들어, Compareable 인터페이스에는 실제로 요구사항이 있습니다. a<b && b < c이면 a < c이면 인터페이스에서는 이것이 정확하다는 보장이 없습니다. 물론 추상 클래스가 문제를 해결할 수는 없지만 위 Equal의 경우 추상 클래스 구현이 추가 요구 사항에 더 부합합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
가장 많이 사용하는 곳이 템플릿 방식(Template Method)을 구현하는 곳이죠?
예를 들어 원격 서비스를 위한 로컬 프록시 배치를 작성하려고 합니다. 이 에이전트 배치의 경우 요청 주소 획득, 요청 전송 및 해당 콘텐츠 획득 단계가 모두 공통적입니다. 문자 인코딩 유형을 정의하는 단계와 응답 콜백을 정의하는 두 단계만 다릅니다.
이때 추상 클래스를 정의하고 요청 프로세스를 완료할 수 있습니다. 차이점은 정의할 실제 하위 클래스에 맡겨집니다. 디자이너가 추상 클래스의 인스턴스화를 [허용하지 않는] 것이 아니라 원격 서비스의 특성을 알기 전에 일부 특성을 결정할 수 없어 인스턴스화가 불가능하다는 것입니다.
JDK의 예는 java.io.InputStream입니다. read(byte[], int, int) 메소드는 java.io.InputStream.read() 메소드를 호출합니다. Read()는 추상 메서드이므로 하위 클래스에서 정의해야 합니다. 소스코드를 통해 학습할 수 있습니다.
으아악클래스를 상속하거나 인터페이스를 구현하는지 확인해야 합니다
일부 공유 메소드가 배치되었을 가능성이 매우 높습니다
그렇지 않다면 인터페이스로 바꿔보는 건 어떨까요
일부 공개 메소드 및 인스턴스 필드가 추출되었을 수 있습니다.
추상 메소드가 없는 추상 클래스가 특별한 의미를 갖는 것은 아닙니다. 이는 단지 추상 클래스의 일반적인 의미일 뿐입니다. 기본 구현을 고려하면 인터페이스를 직접 구현하는 것보다 코드가 덜 필요할 수 있습니다. 반면에 추상 클래스에 하나 또는 두 개의 추상 메소드를 유지하도록 요구하는 이유는 무엇입니까?
반대로 이 클래스의 하위 클래스가 특정 메소드를 생성하기 위해서는 . 물론 이것도 인터페이스의 요구 사항이지만 인터페이스에서는 모든 메서드가 추상 메서드여야 합니다. 그러나 추상 클래스는 하위 클래스에 의해 재정의될 필요가 없는 일부 메서드를 미리 정의할 수 있습니다.
추상 클래스와 인터페이스는 모두 추상화를 위한 것입니다. 추상화의 이점에 대해서는 언급하지 않겠습니다. 예를 들어
Equal인터페이스나 클래스를 구현하려면equal및unequal두 가지 메서드를 정의합니다. 인터페이스를 사용하여 구현된 경우 클래스는 이 두 가지 메서드를 구현해야 합니다. 그러나 추상 클래스로 구현한다면unequal은 추상 클래스에서!equal처럼 구현될 수 있으므로unequal는 그 하위 클래스에 구현되어야 한다.개인적으로는 추상 클래스를 선호합니다(단,
Java는 다중 상속을 지원하지 않습니다). 예를 들어,Compareable인터페이스에는 실제로 요구사항이 있습니다.a<b && b < c이면a < c이면 인터페이스에서는 이것이 정확하다는 보장이 없습니다. 물론 추상 클래스가 문제를 해결할 수는 없지만 위Equal의 경우 추상 클래스 구현이 추가 요구 사항에 더 부합합니다.예:
으아악기반: spring mvc
공통 전역 속성 요청 응답 세션
공통 메소드 getLoginUser()
물론 다른 것들도 있을 것입니다(일부 공통 속성 및 메소드).
컨트롤러가 있으므로 서비스다오도 사용할 수 있습니다.
보통 일부 재설정 코드를 상위 클래스로 추출하여 사용합니다.