1. 추상 클래스
객체는 클래스를 통해 생성되지만 모든 클래스가 특정 객체를 설명할 수 있는 것은 아닙니다.
클래스에 특정 객체를 설명하기에 충분한 정보가 포함되어 있지 않으면 추상 클래스가 됩니다. 추상 클래스는 특성은 동일하지만 성능 세부 사항이 다른 개체 클래스를 추상화한 것입니다. 예를 들어, 새들은 모두 울지만, 서로 다른 새들이 서로 다른 방식으로 울부짖는다는 개념을 추상화할 수 있습니다.
다음 새를 정의합니다.
public abstract class Bird { private String color; public String getColor() { return color; } public void setColor(String color) { this.color = color; } public Bird(){ } public abstract void sing();//鸣叫 } //喜鹊 class Magpie extends Bird{ public void sing() { System.out.println("I can sing in a whisper. "); } }
추상 클래스 특성:
(1) 추상 클래스는 추상 키워드
로 수정됩니다. (2 ) 추상 클래스의 추상 메소드는 abstract 키워드로 수정되며 메소드 본문이 없습니다(구체적인 구현).
(3) 추상 클래스는 비추상 메소드를 포함할 수 있습니다
(4) 추상 클래스는 추상 메소드를 포함할 필요가 없습니다(추상 클래스를 설계하는 것은 의미가 없습니다...). 그러나 메소드의 클래스는 추상 클래스여야 합니다
(5) 추상 클래스의 본질도 클래스이므로 상속만 가능합니다
(6) 추상 클래스는 인스턴스화하거나 새로 만들 수 없습니다. 앞서 말했듯이 특정 객체를 기술하지 않으며 인스턴스화할 수도 없습니다
(7) 추상 클래스는 인스턴스 변수와 생성자를 가질 수 있습니다
2. 인터페이스
인터페이스는 메소드 특성의 모음, 즉 수행할 수 있는 작업을 규정하는 계약입니다. 소프트웨어 설계 프로세스는 구체적인 구현보다는 추상화에 의존합니다.
우리 컴퓨터의 USB 인터페이스와 마찬가지로 하드 드라이브, USB 플래시 드라이브, 휴대폰 등 USB에서 지정한 인터페이스를 구현하기만 하면 컴퓨터에 연결할 수 있습니다.
위의 추상 클래스 예시에서 펭귄, 타조, 오리 등 모든 새가 날 수 있는 것은 아니라는 점을 고려하면 어떻게 해야 할까요? <… _^.
다음 인터페이스를 정의할 수 있습니다.
//Magpie는 IBird에서 인터페이스를 구현할 수 있습니다.public interface IFly { void fly(); }
class Magpie extends Bird implements IFly { public void sing() { System.out.println("I can sing in a whisper. "); } public void fly(){ System.out.println("我会飞了!"); } }
새에게 수영 기능을 추가해야 한다면 어떻게 될까요? 스스로 생각해보세요. . .
인터페이스 특성:
(1) 수식어: public, abstract, default (쓰기 금지)
(2) 키워드: 인터페이스
( 3) 인터페이스의 메소드는 추상 메소드이므로 구현할 수 없습니다.
(4) 인터페이스의 메소드는 기본적으로 공개 추상이며 구현 클래스는 공개 수정을 사용해야 합니다.
(5) 인터페이스의 모든 메소드는 구현 클래스에서 구현되어야 합니다(추상 클래스 제외).
(6) 인터페이스의 변수는 기본적으로 public static final입니다.
(7) 클래스는 여러 인터페이스를 구현할 수 있습니다.
3. 응용 시나리오
1) 추상 클래스는 "is a" 관계를 반영합니다. 특정 클래스의 구현에 공통점이 있으면 추상화할 수 있습니다. 추상 클래스가 생성되어 추상 클래스가 공통 코드를 구현할 수 있도록 하고, 각 하위 클래스별로 개인화된 메서드를 구현합니다.
2) 인터페이스는 "like a" 관계를 반영하고 다양한 유형의 객체의 추상적인 동작을 나타냅니다. 예를 들어 비행기와 새는 날 수 있고, 날기 위한 인터페이스는 분리할 수 있지만 같은 종류는 아니다.
3) 소프트웨어 설계에서는 구현과 인터페이스를 분리하고 변경 사항을 캡슐화해야 할 때 인터페이스 지향 프로그래밍이 특히 중요합니다.
예를 들어 IOC 사고에서는 클라이언트가 어떤 클래스인지 상관하지 않고 특정 개체가 컨테이너에 의해 주입됩니다.
또 다른 예는 두 시스템 간의 상호 작용입니다. 좋은 디자인은 양쪽이 인터페이스를 제공하고 내부 구현에 신경 쓰지 않는다는 것입니다. 이렇게 하면 변경 사항을 캡슐화하는 동안 결합이 줄어듭니다.
열기 및 닫기 원리, 인터페이스 격리, 종속성 반전, 어댑터 패턴 등 많은 디자인 원칙, 디자인 아이디어 및 디자인 패턴은 인터페이스 지향 프로그래밍의 중요성을 반영합니다.