질문자 :Houman
저는 최근에 Interface와 Abstract 클래스의 차이점에 대한 질문을 받은 두 번의 전화 인터뷰를 받았습니다. 내가 생각할 수 있는 모든 측면을 설명했지만 그들은 내가 구체적으로 언급하기를 기다리고 있는 것 같고 그것이 무엇인지 모르겠습니다.
제 경험에 비추어 볼 때 다음이 사실이라고 생각합니다. 중요한 포인트를 놓치고 있다면 알려주세요.
상호 작용:
인터페이스에 선언된 모든 단일 메서드는 하위 클래스에서 구현되어야 합니다. 이벤트, 대리자, 속성(C#) 및 메서드만 인터페이스에 존재할 수 있습니다. 클래스는 여러 인터페이스를 구현할 수 있습니다.
추상 클래스:
추상 메서드만 하위 클래스에서 구현해야 합니다. Abstract 클래스는 구현이 있는 일반 메서드를 가질 수 있습니다. 추상 클래스는 이벤트, 대리자, 속성 및 메서드 옆에 클래스 변수를 가질 수도 있습니다. 클래스는 C#에서 다중 상속이 없기 때문에 하나의 추상 클래스만 구현할 수 있습니다.
그 후 면접관은 "추상 메소드만 있는 추상 클래스가 있다면 어떨까요? 인터페이스와 어떻게 다를까요?"라는 질문을 던졌습니다. 답은 몰랐는데 위에서 말한 상속인 것 같은데 맞나요?
다른 면접관이 인터페이스 내부에 Public 변수가 있는 경우 추상 클래스와 어떻게 다른지 물었습니다. 나는 당신이 인터페이스 안에 공용 변수를 가질 수 없다고 주장했습니다. 나는 그가 무엇을 듣고 싶어하는지 몰랐지만 그 역시 만족하지 못했다.
참조 :
비유하자면 공군에 있을 때 조종사 훈련을 받고 USAF(미공군) 조종사가 되었습니다. 그 당시 나는 비행할 자격이 없었고 항공기 유형 훈련에 참석해야 했습니다. 자격을 얻은 후에는 조종사(추상 클래스)와 C-141 파일럿(콘크리트 클래스)이 되었습니다. 내 임무 중 하나에서 나는 추가 임무인 안전 책임자를 받았습니다. 이제 나는 여전히 조종사이자 C-141 조종사였지만 안전 장교의 직무도 수행했습니다(말하자면 ISafetyOfficer를 구현했습니다). 조종사는 안전 장교가 될 필요가 없었습니다. 다른 사람들도 그렇게 할 수 있었습니다.
모든 USAF 조종사는 공군 전체의 특정 규정을 따라야 하며 모든 C-141(또는 F-16 또는 T-38) 조종사는 'USAF 조종사'입니다. 누구나 안전관리자가 될 수 있습니다. 요약하자면:
- 파일럿: 추상 클래스
- C-141 파일럿: 콘크리트 클래스
- ISafety Officer: 인터페이스
추가 참고: 이것은 코딩 권장 사항이 아니라 개념을 설명하는 데 도움이 되도록 비유하기 위한 것입니다. 아래의 다양한 의견을 참조하십시오. 토론은 흥미롭습니다.
귀하의 질문은 "일반 OO"에 대한 것임을 나타내지만 실제로 이러한 용어의 .NET 사용에 초점을 맞추고 있는 것 같습니다.
.NET에서(Java와 유사):
- 인터페이스에는 상태나 구현이 있을 수 없습니다.
- 인터페이스를 구현하는 클래스는 해당 인터페이스의 모든 메서드 구현을 제공해야 합니다.
- 추상 클래스에는 상태(데이터 멤버) 및/또는 구현(메서드)이 포함될 수 있습니다.
- 추상 클래스는 추상 메서드를 구현하지 않고도 상속될 수 있습니다(이러한 파생 클래스 자체가 추상임).
- 인터페이스는 다중 상속될 수 있고 추상 클래스는 그렇지 않을 수 있습니다(이것이 아마도 인터페이스가 추상 클래스와 별도로 존재하는 주요 구체적인 이유일 것입니다. 이는 일반 MI의 많은 문제를 제거하는 다중 상속의 구현을 허용합니다).
일반적인 OO 용어로 차이점이 반드시 잘 정의된 것은 아닙니다. 예를 들어, 유사한 엄격한 정의(인터페이스는 구현을 포함할 수 없는 추상 클래스의 엄격한 하위 집합임)를 보유할 수 있는 C++ 프로그래머가 있는 반면 일부 기본 구현이 있는 추상 클래스는 여전히 인터페이스이거나 비추상 클래스라고 말할 수 있습니다. 클래스는 여전히 인터페이스를 정의할 수 있습니다.
실제로 NVI(비 가상 인터페이스)라는 C++ 관용구가 있습니다. 여기서 공개 메서드는 비공개 가상 메서드에 '썽크'하는 비가상 메서드입니다.
그들이 찾고 있는 답은 근본적이거나 OPPS의 철학적 차이라고 생각합니다.
추상 클래스 상속은 파생 클래스가 추상 클래스의 핵심 속성과 동작을 공유할 때 사용됩니다. 실제로 클래스를 정의하는 동작의 종류.
반면에 인터페이스 상속은 클래스가 반드시 파생 클래스를 정의하지 않는 주변 동작을 공유할 때 사용됩니다.
예를 들어 Car와 Truck은 Automobile 추상 클래스의 많은 핵심 속성과 동작을 공유하지만, Drillers 또는 PowerGenerator와 같은 자동차가 아닌 클래스도 공유하고 반드시 Car 또는 Truck을 정의하지 않는 배기 생성과 같은 일부 주변 동작도 공유합니다. , 따라서 Car, Truck, Driller 및 PowerGenerator는 모두 동일한 인터페이스 IExhaust를 공유할 수 있습니다.
요약: 추상 클래스는 유사하게 보이는 클래스의 클래스 계층을 모델링 하는 데 사용됩니다(예를 들어 Animal은 추상 클래스일 수 있고 Human, Lion, Tiger는 구체적인 파생 클래스일 수 있음).
그리고
Interface는 Interface를 구현하는 클래스의 타입에 상관없이 2개의 유사/비유사 클래스 간의 통신에 사용됩니다. , 당신은 죽을 수 있습니다 수영 할 수 있습니다.
몇 가지 다른 차이점이 있습니다.
인터페이스는 구체적인 구현을 가질 수 없습니다. 추상 기본 클래스는 가능합니다. 이를 통해 구체적인 구현을 제공할 수 있습니다. 인터페이스는 실제로 클래스가 사용되는 방법만 설명하는 반면 추상 기본 클래스는 실제로 더 엄격한 계약을 제공할 수 있습니다. (추상 기본 클래스에는 동작을 정의하는 비가상 멤버가 있을 수 있으므로 기본 클래스 작성자에게 더 많은 제어 권한이 부여됩니다.)
하나의 클래스에서 둘 이상의 인터페이스를 구현할 수 있습니다. 클래스는 단일 추상 기본 클래스에서만 파생될 수 있습니다. 이것은 인터페이스를 사용하는 다형성 계층을 허용하지만 추상 기본 클래스는 허용하지 않습니다. 이것은 또한 인터페이스를 사용하여 의사 다중 상속을 허용합니다.
추상 기본 클래스는 API를 중단하지 않고 v2+에서 수정할 수 있습니다. 인터페이스에 대한 변경은 주요 변경 사항입니다.
[C#/.NET 관련] 인터페이스는 추상 기본 클래스와 달리 값 형식(구조체)에 적용할 수 있습니다. 구조체는 추상 기본 클래스에서 상속할 수 없습니다. 이를 통해 행동 계약/사용 지침을 값 유형에 적용할 수 있습니다.
계승
자동차와 버스를 생각해보자. 서로 다른 두 차량입니다. 그러나 여전히 스티어링, 브레이크, 기어, 엔진 등과 같은 몇 가지 공통 속성을 공유합니다.
따라서 상속 개념을 사용하면 다음과 같이 나타낼 수 있습니다.
public class Vehicle { private Driver driver; private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections). //You can define as many properties as you want here ... }
이제 자전거 ...
public class Bicycle extends Vehicle { //You define properties which are unique to bicycles here ... private Pedal pedal; }
그리고 자동차 ...
public class Car extends Vehicle { private Engine engine; private Door[] doors; }
상속 에 관한 모든 것입니다. 위에서 본 것처럼 객체를 더 단순한 기본 형식과 그 자식으로 분류하는 데 사용합니다.
추상 클래스
추상 클래스는 불완전한 객체입니다. 더 잘 이해하기 위해 차량 비유를 다시 한 번 생각해 보겠습니다.
차량을 운전할 수 있습니다. 오른쪽? 그러나 다른 차량은 다른 방식으로 운전됩니다 ... 예를 들어 자전거를 운전하는 것처럼 자동차를 운전할 수는 없습니다.
그렇다면 차량의 주행 기능은 어떻게 표현해야 할까요? 어떤 차량인지 확인하고 자체 기능으로 운전하는 것이 더 어렵습니다. 새로운 유형의 차량을 추가할 때 Driver 클래스를 계속해서 변경해야 합니다.
여기에 추상 클래스와 메서드의 역할이 있습니다. 모든 상속 자식이 이 기능을 구현해야 함을 알리기 위해 드라이브 메서드를 추상으로 정의할 수 있습니다.
따라서 차량 클래스를 수정하면 ...
//......Code of Vehicle Class abstract public void drive(); //.....Code continues
자전거와 자동차도 운전 방법을 지정해야 합니다. 그렇지 않으면 코드가 컴파일되지 않고 오류가 발생합니다.
간단히 말해서.. 추상 클래스는 일부 불완전한 기능이 있는 부분적으로 불완전한 클래스이며 상속하는 자식이 자체적으로 지정해야 합니다.
인터페이스 인터페이스는 완전히 불완전합니다. 속성이 없습니다. 그들은 상속받은 자녀가 무언가를 할 수 있음을 나타냅니다 ...
다양한 유형의 휴대전화를 가지고 있다고 가정해 보겠습니다. 그들 각각은 다른 기능을 수행하는 다른 방법을 가지고 있습니다. 예: 사람을 부르다. 전화 제조업체는 방법을 지정합니다. 여기에서 휴대폰은 번호를 다이얼할 수 있습니다. 즉, 다이얼이 가능합니다. 이것을 인터페이스로 표현해보자.
public interface Dialable { public void dial(Number n); }
여기에서 Dialable 제작자는 번호를 다이얼하는 방법을 정의합니다. 전화를 걸기 위해 번호를 주기만 하면 됩니다.
// Makers define how exactly dialable work inside. Dialable PHONE1 = new Dialable() { public void dial(Number n) { //Do the phone1's own way to dial a number } } Dialable PHONE2 = new Dialable() { public void dial(Number n) { //Do the phone2's own way to dial a number } } //Suppose there is a function written by someone else, which expects a Dialable ...... public static void main(String[] args) { Dialable myDialable = SomeLibrary.PHONE1; SomeOtherLibrary.doSomethingUsingADialable(myDialable); } .....
이에 따라 추상 클래스 대신 인터페이스를 사용하므로 Dialable을 사용하는 함수 작성자는 해당 속성에 대해 걱정할 필요가 없습니다. 예: 터치 스크린 또는 다이얼 패드가 있습니까? 고정 유선 전화입니까, 아니면 휴대 전화입니까? 다이얼 가능한지 여부만 알면 됩니다. Dialable 인터페이스를 상속(또는 구현)합니까?
그리고 더 중요한 것은 언젠가 다이얼러블을 다른 것으로 바꾸면
...... public static void main(String[] args) { Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2 SomeOtherLibrary.doSomethingUsingADialable(myDialable); } .....
다이얼러블을 사용하는 함수는 다이얼러블 인터페이스에 지정된 것 이외의 세부사항에 의존하지 않기 때문에 코드가 여전히 완벽하게 작동한다는 것을 확신할 수 있습니다. 둘 다 Dialable 인터페이스를 구현하며 이것이 함수가 관심을 갖는 유일한 것입니다.
인터페이스는 개발자가 공통 기능을 공유하는 한 개체 간의 상호 운용성(교환 가능하게 사용)을 보장하기 위해 일반적으로 사용됩니다(전화를 걸기만 하면 유선 전화나 휴대 전화로 변경할 수 있는 것처럼). 간단히 말해서 인터페이스는 속성이 없는 훨씬 단순한 추상 클래스 버전입니다.
또한 원하는 만큼 인터페이스를 구현(상속)할 수 있지만 단일 상위 클래스만 확장(상속)할 수 있습니다.
추가 정보 추상 클래스와 인터페이스
java 를 OOP 언어로 간주하면 Java 8 릴리스로 인해 위 답변의 일부 내용이 더 이상 사용되지 않습니다. 이제 자바 인터페이스는 구체적인 구현과 함께 기본 메소드를 가질 수 있습니다.
Oracle 웹 사이트 interface 와 abstract 클래스 간의 주요 차이점을 제공합니다.
다음과 같은 경우 추상 클래스 사용을 고려하십시오.
- 밀접하게 관련된 여러 클래스 간에 코드를 공유하려고 합니다.
- 추상 클래스를 확장하는 클래스에는 많은 공통 메서드나 필드가 있거나 public 이외의 액세스 수정자가 필요합니다(예: protected 및 private).
- 비정적 또는 비최종 필드를 선언하려고 합니다.
다음과 같은 경우 인터페이스 사용을 고려하십시오.
- 관련되지 않은 클래스가 인터페이스를 구현할 것으로 예상합니다. 예를 들어, 관련 없는 많은 개체가
Serializable 인터페이스를 구현할 수 있습니다. - 특정 데이터 유형의 동작을 지정하고 싶지만 해당 동작을 구현하는 사람에 대해서는 관심이 없습니다.
- 유형의 다중 상속을 활용하려고 합니다.
간단히 말해서 사용하고 싶습니다.
인터페이스: 관련되지 않은 여러 개체로 계약을 구현하려면
추상 클래스: 여러 관련 객체 간에 동일하거나 다른 동작을 구현합니다.
명확하게 이해하기 위해 코드 예제를 살펴보십시오 . 인터페이스와 추상 클래스의 차이점을 어떻게 설명해야 했습니까?
면접관들이 이상한 나무를 짖고 있습니다. C# 및 Java와 같은 언어의 경우 차이가 있지만 C++와 같은 다른 언어에는 차이가 없습니다. 객체지향 이론은 둘을 구별하지 않고 단지 언어의 구문일 뿐입니다.
추상 클래스는 상속될 구현 및 인터페이스(순수 가상 메서드)가 모두 있는 클래스입니다. 인터페이스에는 일반적으로 구현이 없고 순수한 가상 기능만 있습니다.
C# 또는 Java에서 구현이 없는 추상 클래스는 인터페이스에서 상속하는 데 사용되는 구문과 하나만 상속할 수 있다는 사실에서만 인터페이스와 다릅니다.
인터페이스를 구현함으로써 상속("is-a" 관계) 대신 구성("ha-a" 관계)을 달성하게 됩니다. 이는 상속 대신 동작 구성을 달성하기 위해 인터페이스를 사용해야 하는 디자인 패턴과 같은 경우 기억해야 할 중요한 원칙입니다.
개념적으로 말하자면, 언어별 구현, 규칙, 이점을 유지하고 누군가 또는 둘 다를 사용하여 프로그래밍 목표를 달성하는 것은 코드/데이터/속성, ㅋㅋㅋ, 단일 또는 다중 상속을 가질 수 있거나 가질 수 없습니다.
1- 추상(또는 순수 추상) 클래스는 계층 구조를 구현하기 위한 것입니다. 비즈니스 개체가 구조적으로 다소 유사하여 부모-자식(계층 구조) 종류의 관계만 나타내는 경우 상속/추상 클래스가 사용됩니다. 비즈니스 모델에 계층 구조가 없으면 상속을 사용해서는 안 됩니다(여기서 프로그래밍 논리에 대해 말하는 것이 아닙니다. 예를 들어 일부 디자인 패턴에는 상속이 필요함). 개념적으로 추상 클래스는 OOP에서 비즈니스 모델의 계층 구조를 구현하는 방법이며 인터페이스와 관련이 없으며 실제로 추상 클래스를 인터페이스와 비교하는 것은 개념적으로 완전히 다른 것이므로 의미가 없으며 인터뷰에서 확인하기 위해 묻는 것입니다. 개념은 구현과 관련하여 둘 다 다소 동일한 기능을 제공하고 우리 프로그래머는 일반적으로 코딩에 대해 더 강조하기 때문입니다. [추상화는 추상 클래스와 다르다는 점을 염두에 두십시오.]
2- 인터페이스는 하나 이상의 기능 세트로 표현되는 완전한 비즈니스 기능인 계약입니다. 그렇기 때문에 상속되지 않고 구현됩니다. 비즈니스 개체(계층 구조의 일부이든 아니든)에는 완전한 비즈니스 기능이 여러 개 있을 수 있습니다. 추상 클래스와 관련이 없다는 것은 일반적으로 상속을 의미합니다. 예를 들어, 인간은 뛸 수 있고, 코끼리는 뛸 수 있고, 새는 뛸 수 있습니다. 다른 계층 구조의 이러한 모든 개체는 RUN 인터페이스 또는 EAT 또는 SPEAK 인터페이스를 구현합니다. 이러한 인터페이스를 구현하는 각 유형에 대한 추상 클래스가 있는 것으로 구현할 수 있으므로 구현에 들어가지 마십시오. 모든 계층의 개체는 계층과 관련이 없는 기능(인터페이스)을 가질 수 있습니다.
내 생각에 인터페이스는 다중 상속을 달성하거나 공개 동작을 노출하기 위해 발명되지 않았으며 유사하게 순수 추상 클래스는 인터페이스를 무시하지 않지만 인터페이스는 객체가 (해당 인터페이스의 기능을 통해) 수행할 수 있는 기능이고 추상 클래스는 부모의 핵심 구조(속성+기능)를 갖는 자식을 생성하기 위한 계층의 부모
차이점에 대해 물으면 명시적으로 묻지 않는 한 실제로는 언어별 구현의 차이가 아니라 개념적 차이입니다.
저는 두 면접관 모두 이 두 가지 사이에 한 줄의 직접적인 차이점을 기대하고 있었고 실패했을 때 ONE을 OTHER로 구현하여 이러한 차이로 이끌려고 했습니다.
추상 메서드만 있는 추상 클래스가 있다면 어떨까요?
인터페이스와 추상 클래스의 Depth Details를 설명하겠습니다. 인터페이스와 추상 클래스에 대한 개요를 알고 있다면 인터페이스를 사용해야 하는 시점과 추상 클래스를 사용해야 하는 시점에 대한 첫 번째 질문이 떠오릅니다. 따라서 Interface 및 Abstract 클래스에 대한 설명은 아래에서 확인하시기 바랍니다.
언제 인터페이스를 사용해야 합니까?
구현에 대해 모른다면 요구 사항 사양만 있으면 인터페이스로 이동합니다.
추상 클래스는 언제 사용해야 합니까?
구현을 알고 있지만 완전히(부분적으로 구현)하지 않은 경우 추상 클래스를 사용합니다.
상호 작용
기본적으로 모든 메서드는 공용 추상화로 인터페이스가 100% 순수 추상화를 의미합니다.
추상적 인
구체적인 방법과 추상적인 방법을 가질 수 있습니다. 구체적 방법은 추상 클래스에 구현되어 있습니다. 추상 클래스는 추상으로 선언된 클래스입니다. 추상 메서드를 포함할 수도 있고 포함하지 않을 수도 있습니다.
상호 작용
인터페이스를 private, protected로 선언할 수 없습니다.
Q. 인터페이스를 private 및 protected로 선언하지 않는 이유는 무엇입니까?
기본적으로 인터페이스 메서드는 공개 추상이므로 인터페이스를 비공개 및 보호로 선언하지 않는 이유입니다.
인터페이스 방식
또한 인터페이스를 private,protected,final,static,synchronized,native로 선언할 수 없습니다.....
나는 그 이유를 제시할 것이다: 우리가 인터페이스의 객체를 생성할 수 없고 동기화가 객체에 대한 작업이기 때문에 우리가 동기화된 메소드를 선언하지 않는 이유와 우리가 동기화된 메소드를 선언하지 않는 이유 과도 개념은 또한 동기화된 과도 작업 때문에 적용할 수 없다.
추상적 인
우리는 public, private final static....과 함께 행복하게 사용합니다. 추상적으로 적용할 수 있는 제한이 없음을 의미합니다.
상호 작용
변수는 인터페이스에서 기본적으로 public static final로 선언되므로 우리도 변수를 private, protected로 선언하지 않습니다.
Volatile 수정자는 기본적으로 공용 정적 최종 변수이기 때문에 인터페이스에 적용할 수 없습니다. 변수에 값을 할당하면 값을 변경할 수 없으며 인터페이스에 변수를 선언한 후에는 변수를 할당해야 합니다.
그리고 volatile 변수는 계속 변경되므로 opp입니다. 마지막으로 인터페이스에서 휘발성 변수를 사용하지 않는 이유입니다.
추상적 인
추상 변수는 public static final로 선언할 필요가 없습니다.
이 기사가 유용하기를 바랍니다.
닷넷의 경우,
두 번째 면접관에 대한 귀하의 답변은 첫 번째 면접관에 대한 답변이기도 합니다... 추상 클래스는 구현을 가질 수 있고, 그리고 상태는 인터페이스를 가질 수 없습니다...
편집: 또 다른 메모에서, 인터페이스 '구현하도록 정의된' 클래스를 설명하기 위해 '하위 클래스'(또는 '상속' 구문)라는 구문을 사용하지도 않습니다. 나에게 인터페이스는 해당 인터페이스를 '구현'하도록 정의된 경우 클래스가 따라야 하는 계약의 정의입니다. 아무 것도 상속하지 않습니다... 명시적으로 모든 것을 직접 추가해야 합니다.
Interface : 서로 관련되거나 관련되지 않을 수 있는 구성 요소에 대한 규칙을 암시하려는 경우 사용해야 합니다.
장점:
- 다중 상속 허용
- 컨텍스트에서 정확히 어떤 종류의 객체가 사용되고 있는지 노출하지 않음으로써 추상화를 제공합니다.
- 계약의 특정 서명으로 일관성을 제공합니다.
단점:
- 정의된 모든 계약을 구현해야 합니다.
- 변수나 대리자를 가질 수 없음
- 한 번 정의되면 모든 클래스를 중단하지 않고 변경할 수 없습니다.
추상 클래스 : 서로 관련된 구성 요소에 대한 일부 기본 또는 기본 동작 또는 구현을 원하는 경우에 사용해야 합니다.
장점:
- 인터페이스보다 빠름
- 구현에 유연성이 있음(전체 또는 부분적으로 구현할 수 있음)
- 파생 클래스를 손상시키지 않고 쉽게 변경할 수 있습니다.
단점:
- 인스턴스화할 수 없음
- 다중 상속을 지원하지 않습니다.
답변이 너무 깁니다.
이것은 또한 Java가 클래스에 대한 단일 상속만 지원하지만 인터페이스에는 제한을 두지 않는 이유를 설명합니다. 구체적인 객체는 다른 것이 될 수 없지만 다른 동작을 가질 수 있기 때문입니다.
디자인적인 차이가 아닌 기술적인 차이를 주셨기 때문에 답변이 마음에 들지 않았던 것 같습니다. 질문은 저에게 트롤 질문과 같습니다. 사실 인터페이스와 추상 클래스는 성격이 완전히 다르기 때문에 비교할 수 없습니다. 인터페이스의 역할과 추상 클래스의 역할에 대한 제 비전을 알려드리겠습니다.
interface: 더 유지 보수 가능하고 확장 가능하며 테스트 가능한 응용 프로그램을 갖기 위해 계약을 보장하고 클래스 간의 낮은 결합을 만드는 데 사용됩니다.
추상 클래스: 동일한 책임의 클래스 간에 일부 코드를 인수분해하는 데만 사용됩니다. 이것이 OOP에서 다중 상속이 나쁜 주된 이유입니다. 클래스가 많은 책임을 처리해서는 안 되기 때문입니다( 대신 구성 사용).
따라서 인터페이스는 실제 아키텍처 역할을 하는 반면 추상 클래스는 거의 구현의 세부 사항일 뿐입니다(물론 올바르게 사용하는 경우).
- 상호 작용:
- 메서드를 구현(또는 정의)하지 않고 파생 클래스에서 수행합니다.
- 인터페이스에서 멤버 변수를 선언하지 않습니다.
- 인터페이스는 HAS-A 관계를 표현합니다. 즉, 객체의 마스크입니다.
- 추상 클래스:
- 추상 클래스에서 메소드를 선언하고 정의할 수 있습니다.
- 우리는 생성자를 숨깁니다. 즉, 직접 생성된 개체가 없습니다.
- 추상 클래스는 멤버 변수를 보유할 수 있습니다.
- 파생 클래스는 파생 클래스의 객체가 마스킹되지 않고 추상 클래스로 상속된다는 것을 의미하는 추상 클래스로 상속됩니다. 이 경우 관계는 IS-A입니다.
이것은 내 의견입니다.
After all that, the interviewer came up with the question "What if you had an Abstract class with only abstract methods? How would that be different from an interface?"
문서 에서는 추상 클래스가 추상 메서드 선언만 포함하는 경우 대신 인터페이스로 선언해야 한다고 분명히 말합니다.
An another interviewer asked me what if you had a Public variable inside the interface, how would that be different than in Abstract Class?
인터페이스의 변수는 기본적으로 public static 및 final입니다. 추상 클래스의 모든 변수가 공용이면 어떻게 될까요? 인터페이스의 변수와 달리 여전히 정적이지 않고 최종적이지 않을 수 있습니다.
마지막으로 위에서 언급한 것에 한 가지 더 추가할 것입니다. 추상 클래스는 여전히 클래스이고 단일 상속 트리에 속하지만 인터페이스는 다중 상속에 존재할 수 있습니다.
Jeffrey Richter가 C#을 통해 CLR에서 복사...
"기본형을 디자인해야 하나요, 인터페이스를 디자인해야 하나요?"라는 질문을 자주 듣습니다. 답이 항상 명료한 것은 아닙니다.
다음은 도움이 될 수 있는 몇 가지 지침입니다.
■■ IS-A 대 CAN-DO 관계 유형은 하나의 구현만 상속할 수 있습니다. 파생 형식이 기본 형식과 IS-A 관계를 주장할 수 없는 경우 기본 형식을 사용하지 마십시오. 인터페이스를 사용합니다. 인터페이스는 CAN-DO 관계를 의미합니다. CAN-DO 기능이 다양한 객체 유형에 속하는 것으로 나타나면 인터페이스를 사용하십시오. 예를 들어 형식은 자신의 인스턴스를 다른 형식으로 변환할 수 있고(IConvertible), 형식은 자신의 인스턴스를 직렬화할 수 있습니다(ISerializable). 값 형식은 System.ValueType에서 파생되어야 하므로 파생될 수 없습니다. 임의의 기본 클래스에서. 이 경우 CAN-DO 관계를 사용하고 인터페이스를 정의해야 합니다.
■■ 사용 용이성 일반적으로 개발자는 인터페이스의 모든 메소드를 구현하는 것보다 기본 유형에서 파생된 새 유형을 정의하는 것이 더 쉽습니다. 기본 형식은 많은 기능을 제공할 수 있으므로 파생 형식은 동작에 대해 상대적으로 약간만 수정하면 됩니다. 인터페이스를 제공하는 경우 새 형식은 모든 멤버를 구현해야 합니다.
■■ 일관된 구현 인터페이스 계약이 아무리 잘 문서화되어 있더라도 모든 사람이 계약을 100% 올바르게 구현하는 것은 거의 없습니다. 사실 COM은 바로 이 문제로 인해 어려움을 겪고 있습니다. 이것이 일부 COM 개체가 Microsoft Word 또는 Windows Internet Explorer에서만 올바르게 작동하는 이유입니다. 기본 유형에 좋은 기본 구현을 제공하면 작동하고 잘 테스트된 유형을 사용하기 시작합니다. 그런 다음 수정이 필요한 부품을 수정할 수 있습니다.
■■ 버전 관리 기본 유형에 메소드를 추가하면 파생 유형이 새 메소드를 상속하고 작동하는 유형을 사용하여 시작하고 사용자의 소스 코드를 다시 컴파일할 필요도 없습니다. 인터페이스에 새 멤버를 추가하면 인터페이스의 상속자가 소스 코드를 변경하고 다시 컴파일해야 합니다.
인터페이스는 서비스 또는 서비스 집합에 대한 계약을 정의합니다. 완전히 관련이 없는 두 클래스가 동일한 인터페이스를 구현할 수 있지만 구현하는 인터페이스 유형의 매개변수로 서로 바꿔서 사용할 수 있다는 점에서 수평적 방식으로 다형성을 제공합니다. 두 클래스 모두 인터페이스에 의해 정의된 서비스 집합을 충족하기로 약속했기 때문입니다. 인터페이스는 구현 세부 정보를 제공하지 않습니다.
추상 클래스는 하위 클래스에 대한 기본 구조와 선택적으로 부분 구현을 정의합니다. 추상 클래스는 수직적이지만 방향성 있는 방식으로 다형성을 제공합니다. 추상 클래스를 상속하는 모든 클래스는 해당 추상 클래스의 인스턴스로 취급될 수 있지만 그 반대는 불가능합니다. 추상 클래스는 구현 세부 사항을 포함할 수 있고 종종 포함하지만 자체적으로 인스턴스화할 수 없습니다. 하위 클래스만 "새롭게" 만들 수 있습니다.
C#은 인터페이스 상속도 허용합니다.
대부분의 답변은 추상 클래스와 인터페이스의 기술적 차이점 에 초점을 맞추고 있지만 기술적으로 인터페이스는 기본적으로 일종의 추상 클래스(데이터나 구현이 없는 것)이기 때문에 개념적 차이가 훨씬 더 흥미롭고 그것이 무엇일 수도 있다고 생각합니다. 면접관이 뒤따른다.
인터페이스 는 계약 입니다. 그것은 "이것이 우리가 서로 이야기하는 방법입니다"라고 지정합니다. 이 모든 구현이 안 있기 때문에 그것은 어떤 구현을 가질 수 없습니다. 계약입니다. C의 .h 헤더 파일과 같습니다.
추상 클래스 는 불완전한 구현 입니다. 클래스는 인터페이스를 구현하거나 구현하지 않을 수 있으며 추상 클래스는 인터페이스를 완전히 구현할 필요가 없습니다. 구현이 없는 추상 클래스는 일종의 쓸모가 없지만 완전히 합법적입니다.
인터페이스는 당신이 그것을 사용하는 방법에 관한 것입니다 반면 추상적 여부를 기본적으로 모든 클래스는, 그것이 무엇인지에 관한 것입니다. 예를 들면: Animal 은 몇 가지 기본적인 대사 기능을 구현하고 구현을 제공하지 않고 호흡과 운동에 대한 추상 메서드를 지정하는 추상 클래스일 수 있습니다. 왜냐하면 그것이 아가미나 폐를 통해 호흡해야 하는지, 그리고 그것이 날고, 수영하고, 걷는지 알 수 없기 때문입니다. 또는 크롤링. Mount 는 동물이 어떤 종류의 동물인지(또는 동물인지 여부) 모른 채 동물을 탈 수 있도록 지정하는 인터페이스일 수 있습니다.
배후에서 인터페이스가 기본적으로 추상 메서드만 있는 추상 클래스라는 사실은 중요하지 않습니다. 개념적으로 완전히 다른 역할을 수행합니다.
전문가로부터 이론적인 지식을 얻었을 수 있으므로 여기에서 모든 것을 반복하는 데 많은 단어를 소비하지 않고 Interface 및 Abstract class 사용할 수 있거나 사용할 수 없는 간단한 예를 들어 설명하겠습니다.
자동차의 모든 기능을 나열하는 애플리케이션을 설계한다고 가정합니다. DigitalFuelMeter, Air Conditioning, Seat 조정 등과 같은 속성 중 일부는 모든 자동차에 공통적이므로 다양한 지점에서 공통 상속이 필요합니다. 마찬가지로 제동 시스템(ABS, EBD)과 같은 속성 중 일부가 일부 자동차에만 적용되므로 일부 클래스에 대해서만 상속이 필요합니다.
아래 클래스는 모든 자동차의 기본 클래스 역할을 합니다.
public class Cars { public string DigitalFuelMeter() { return "I have DigitalFuelMeter"; } public string AirCondition() { return "I have AC"; } public string SeatAdjust() { return "I can Adjust seat"; } }
각 Car에 대해 별도의 클래스가 있다고 가정합니다.
public class Alto : Cars { // Have all the features of Car class } public class Verna : Cars { // Have all the features of Car class + Car need to inherit ABS as the Braking technology feature which is not in Cars } public class Cruze : Cars { // Have all the features of Car class + Car need to inherit EBD as the Braking technology feature which is not in Cars }
Verna 및 Cruze 차량(Alto에는 적용되지 않음)에 대한 제동 기술을 상속하기 위한 방법이 필요하다고 가정합니다. 둘 다 제동 기술을 사용하지만 "기술"이 다릅니다. 그래서 우리는 메서드가 Abstract로 선언되고 자식 클래스에서 구현되어야 하는 추상 클래스를 만들고 있습니다.
public abstract class Brake { public abstract string GetBrakeTechnology(); }
이제 우리는 이 추상 클래스에서 상속하려고 하며 제동 시스템 유형은 Verna 및 Cruze에서 구현됩니다.
public class Verna : Cars,Brake { public override string GetBrakeTechnology() { return "I use ABS system for braking"; } } public class Cruze : Cars,Brake { public override string GetBrakeTechnology() { return "I use EBD system for braking"; } }
위의 두 클래스의 문제가 보이시나요? 메서드가 자식에서 구현되더라도 C#.Net에서 허용하지 않는 여러 클래스에서 상속합니다. 여기에 인터페이스가 필요합니다.
interface IBrakeTechnology { string GetBrakeTechnology(); }
그리고 구현은 다음과 같습니다.
public class Verna : Cars, IBrakeTechnology { public string GetBrakeTechnology() { return "I use ABS system for braking"; } } public class Cruze : Cars, IBrakeTechnology { public string GetBrakeTechnology() { return "I use EBD system for braking"; } }
이제 Verna와 Cruze는 Interface의 도움으로 자체 제동 기술로 다중 상속을 달성할 수 있습니다.
인터페이스는 특정 동작을 적용하기 위한 가벼운 방법입니다. 그것은 생각하는 한 가지 방법입니다.
1) 인터페이스는 순수 추상 클래스로 볼 수 있으며, 동일하지만 그럼에도 불구하고 인터페이스를 구현하고 추상 클래스에서 상속하는 것은 동일하지 않습니다. 이 순수 추상 클래스에서 상속할 때 계층 구조 -> 상속을 정의하는 것입니다. 인터페이스를 구현하면 그렇지 않고 원하는 만큼 인터페이스를 구현할 수 있지만 하나의 클래스에서만 상속할 수 있습니다.
2) 인터페이스에서 속성을 정의할 수 있으므로 해당 인터페이스를 구현하는 클래스에는 해당 속성이 있어야 합니다.
예를 들어:
public interface IVariable { string name {get; set;} }
해당 인터페이스를 구현하는 클래스에는 이와 같은 속성이 있어야 합니다.
이 질문은 꽤 오래되었지만 인터페이스에 찬성하여 한 가지 다른 점을 추가하고 싶습니다.
인터페이스는 의존성 주입 도구를 사용하여 주입할 수 있으며 추상 클래스 주입은 거의 지원하지 않습니다.
내 다른 답변 에서 주로 하나와 다른 것을 사용할 때를 다룹니다.
내 경험에 따르면 인터페이스는 동일한 메서드 또는 메서드에 각각 응답해야 하는 여러 클래스가 있을 때 가장 잘 사용되므로 해당 클래스의 공통 인터페이스에 대해 작성되는 다른 코드에서 상호 교환 가능하게 사용할 수 있습니다. 인터페이스의 가장 좋은 사용은 프로토콜이 중요하지만 기본 논리가 각 클래스마다 다를 수 있는 경우입니다. 그렇지 않으면 논리를 복제하려는 경우 대신 추상 클래스 또는 표준 클래스 상속을 고려하십시오.
인터페이스 유형 대 추상 기본 클래스
Pro C# 5.0 및 .NET 4.5 Framework 책에서 수정했습니다.
인터페이스 유형은 추상 기본 클래스와 매우 유사해 보일 수 있습니다. 클래스가 추상으로 표시되면 모든 파생 형식에 다형성 인터페이스를 제공하기 위해 추상 멤버를 원하는 수만큼 정의할 수 있음을 상기하십시오. 그러나 클래스가 추상 멤버 집합을 정의하는 경우에도 생성자, 필드 데이터, 비추상 멤버(구현 포함) 등을 자유롭게 정의할 수 있습니다. 반면 인터페이스에는 추상 멤버 정의만 포함됩니다. 추상 부모 클래스에 의해 설정된 다형성 인터페이스는 파생 형식만 추상 부모에 의해 정의된 멤버를 지원한다는 점에서 한 가지 주요 제한 사항이 있습니다. 그러나 더 큰 소프트웨어 시스템에서는 System.Object 외에 공통 부모가 없는 여러 클래스 계층을 개발하는 것이 매우 일반적입니다. 추상 기본 클래스의 추상 멤버는 파생 형식에만 적용되므로 동일한 다형성 인터페이스를 지원하도록 다른 계층 구조의 형식을 구성할 방법이 없습니다. 예를 들어 다음 추상 클래스를 정의했다고 가정합니다.
public abstract class CloneableType { // Only derived types can support this // "polymorphic interface." Classes in other // hierarchies have no access to this abstract // member. public abstract object Clone(); }
이 정의가 주어지면 CloneableType을 확장하는 멤버만 Clone() 메서드를 지원할 수 있습니다. 이 기본 클래스를 확장하지 않는 새 클래스 세트를 생성하면 이 다형성 인터페이스를 얻을 수 없습니다. 또한 C#은 클래스에 대한 다중 상속을 지원하지 않는다는 것을 기억할 수 있습니다. 따라서 Car이고 CloneableType인 MiniVan을 만들고 싶다면 그렇게 할 수 없습니다.
// Nope! Multiple inheritance is not possible in C# // for classes. public class MiniVan : Car, CloneableType { }
짐작할 수 있듯이 인터페이스 유형이 구출됩니다. 인터페이스가 정의되면 모든 클래스 또는 구조, 계층 구조, 네임스페이스 또는 어셈블리(모든 .NET 프로그래밍 언어로 작성됨) 내에서 인터페이스를 구현할 수 있습니다. 보시다시피 인터페이스는 매우 다형성입니다. System 네임스페이스에 정의된 ICloneable이라는 표준 .NET 인터페이스를 고려하십시오. 이 인터페이스는 Clone()이라는 단일 메서드를 정의합니다.
public interface ICloneable { object Clone(); }
두 번째 질문에 대한 답변 : interface 정의된 public 변수는 기본적으로 static final 이고 abstract public 변수는 인스턴스 변수입니다.
OOP에서 인터페이스와 추상 클래스의 동작(및 언어에서 이를 처리하는 방법)을 이해하는 것이 확실히 중요하지만 각 용어가 정확히 무엇을 의미하는지 이해하는 것도 중요하다고 생각합니다. if 명령이 용어의 의미와 정확히 일치하지 않는다고 상상할 수 있습니까? 또한 실제로 일부 언어는 인터페이스와 추상화 간의 차이를 훨씬 더 줄이고 있습니다. 우연히 두 용어가 거의 동일하게 작동한다면 최소한 둘 중 하나가 있어야 할 위치(및 이유)를 스스로 정의할 수 있습니다. 사용.
일부 사전과 다른 글꼴을 읽으면 동일한 용어에 대해 다른 의미를 찾을 수 있지만 몇 가지 공통된 정의가 있습니다. 나는 이 사이트 에서 찾은 이 두 가지 의미가 정말, 정말 좋고, 적절하다고 생각한다.
상호 작용:
개별적이고 때로는 양립할 수 없는 요소가 효과적으로 조정될 수 있게 하는 사물 또는 상황.
추상적 인:
더 광범위하거나 더 일반적인 것, 또는 여러 가지의 본질적 특성을 그 자체에 집중시키는 것. 본질.
예시:
당신은 차를 샀고 연료가 필요합니다.
귀하의 자동차 모델은 ABC 장르의 XYZ 이므로 자동차의 특정 인스턴스인 콘크리트 자동차입니다. 자동차는 실제 물건이 아닙니다. 사실 특정 객체를 생성하는 것은 추상적인 기준(자질)의 집합입니다. 요컨대, Car 는 추상 클래스 이며 "보다 광범위하거나 더 일반적인 것의 본질적인 특성을 자체적으로 집중하는 것" 입니다.
자동차 설명서 사양과 일치하는 유일한 연료는 자동차 탱크를 채우는 데 사용해야 합니다. 실제로 어떤 연료를 넣어도 제한은 없으나 지정된 연료로만 엔진이 제대로 작동하므로 요구 사항을 따르는 것이 좋습니다. 요구 사항은 같은 장르의 다른 자동차로, 받아들이라고 ABC , 연료의 표준 세트.
객체 지향 보기에서 특정 장르의 자동차에 대한 구체적인 연료가 없기 때문에 ABC 당신의 자동차가 Fuel 또는 VehicularFuel 추상 클래스를 받아들일 수 있지만, 기존 차량 연료 중 일부만이 사양을 충족하고 자동차 매뉴얼의 요구 사항을 구현한다는 것을 기억해야 합니다. ABCGenreFuel 인터페이스를 구현해야 합니다. 이 인터페이스는 "... 분리되고 때로는 호환되지 않는 요소가 효과적으로 조정되도록 합니다 ." .
부록
또한 클래스라는 용어의 의미를 염두에 두어야 한다고 생각합니다. 이는 (이전에 언급한 동일한 사이트에서) 다음과 같습니다.
수업:
공통된 속성, 특성, 자질 또는 특성으로 인해 그룹을 구성하는 것으로 간주되는 여러 사람 또는 사물; 친절한;
이런 식으로 클래스(또는 추상 클래스)는 인터페이스와 같은 공통 속성만 나타내지 않고 공통 속성을 가진 일종의 그룹을 나타내야 합니다. 인터페이스는 종류를 나타낼 필요가 없습니다. 공통 속성을 나타내야 합니다. 이런 식으로 클래스와 추상 클래스는 인간이 포유류처럼 어떤 종류를 나타내기 때문에 측면을 자주 변경하지 않아야 하는 것을 나타내는 데 사용할 수 있다고 생각합니다. 종류는 그렇게 자주 바뀌지 않아야 합니다.
코딩 관점에서
추상 클래스에 추상 메서드만 있는 경우 인터페이스가 추상 클래스를 대체할 수 있습니다. 그렇지 않으면 Abstract 클래스를 인터페이스로 변경하면 상속이 제공하는 코드 재사용성을 잃게 됩니다.
디자인 관점에서
"Is" 관계이고 하위 집합 또는 모든 기능이 필요한 경우 추상 클래스로 유지합니다. "해야 할 일"인 경우 인터페이스로 유지하십시오.
필요한 것을 결정하십시오: 정책 시행 또는 코드 재사용성 및 정책.
헐; 박사; "A" 관계가 표시되면 상속/추상 클래스를 사용합니다. "has" 관계를 볼 때 멤버 변수를 만듭니다. "외부 공급자에 의존"이 표시되면 인터페이스를 구현(상속 아님)합니다.
인터뷰 질문: 인터페이스와 추상 클래스의 차이점은 무엇입니까? 그리고 언제 무엇을 사용할지 어떻게 결정합니까? 나는 주로 아래 답변 중 하나 또는 모두를 얻습니다. 답변 1: 추상 클래스 및 인터페이스의 개체를 만들 수 없습니다.
ZK(내 이니셜): 둘 중 하나의 개체를 만들 수 없습니다. 따라서 이것은 차이가 아닙니다. 이것은 인터페이스와 추상 클래스의 유사점입니다. 카운터 질문: 추상 클래스 또는 인터페이스의 개체를 만들 수 없는 이유는 무엇입니까?
답변 2: 추상 클래스는 부분/기본 구현으로 함수 본문을 가질 수 있습니다.
ZK: 카운터 질문: 순수 추상 클래스로 변경하면 모든 가상 기능을 추상으로 표시하고 가상 기능에 대한 기본 구현을 제공하지 않습니다. 추상 클래스와 인터페이스를 동일하게 만들까요? 그리고 그 이후에 서로 바꿔서 사용할 수 있습니까?
답변 3: 인터페이스는 다중 상속을 허용하고 추상 클래스는 허용하지 않습니다.
ZK: 카운터 질문: 정말 인터페이스에서 상속합니까? 아니면 인터페이스를 구현하고 추상 클래스에서 상속합니까? 구현과 상속의 차이점은 무엇입니까? 이러한 반대 질문은 후보자를 실망시키고 대부분의 사람들이 머리를 긁적이거나 다음 질문으로 넘어가게 만듭니다. 그래서 사람들은 객체 지향 프로그래밍의 이러한 기본 빌딩 블록에 도움이 필요하다고 생각합니다. 원래 질문에 대한 답변과 모든 반대 질문은 영어와 UML에서 찾을 수 있습니다. 이 두 구조를 더 잘 이해하려면 최소한 아래 내용을 알아야 합니다.
일반 명사: 일반 명사는 같은 종류나 종류의 사물에 "공통"으로 주어지는 이름입니다. 예를 들어 과일, 동물, 도시, 자동차 등
고유명사: 고유명사는 사물, 장소 또는 사물의 이름입니다. 애플, 캣, 뉴욕, 혼다 어코드 등
자동차는 일반 명사입니다. 그리고 Honda Accord는 고유명사이고, 아마도 두 개의 명사를 사용하여 만든 고유명사인 복합 고유명사일 것입니다.
UML 파트로 이동합니다. 아래 관계에 익숙해야 합니다.
아래의 두 문장을 생각해보자. - HondaAccord는 차인가? - HondaAccord에 차가 있습니까?
어느 것이 맞는 것 같습니까? 평범한 영어와 이해력. HondaAccord와 Cars는 "A" 관계를 공유합니다. 혼다 어코드에는 차가 없습니다. 그것은 "자동차"입니다. Honda Accord에는 뮤직 플레이어가 "있다".
두 엔터티가 "A" 관계를 공유하는 경우 상속을 위한 더 나은 후보입니다. 관계가 있음은 멤버 변수를 생성하기에 더 좋은 후보입니다. 이를 통해 코드는 다음과 같이 보입니다.
abstract class Car { string color; int speed; } class HondaAccord : Car { MusicPlayer musicPlayer; }
이제 Honda는 뮤직 플레이어를 제조하지 않습니다. 아니면 적어도 그들의 주요 사업은 아닙니다.
그래서 그들은 다른 회사에 연락하여 계약을 체결합니다. 여기에서 전원을 수신하고 이 두 와이어의 출력 신호를 수신하면 이 스피커에서 제대로 재생됩니다.
이것은 Music Player를 인터페이스에 대한 완벽한 후보로 만듭니다. 연결이 제대로 작동하는 한 누가 지원을 제공하는지 상관하지 않습니다.
LG의 MusicPlayer를 Sony 또는 다른 방법으로 교체할 수 있습니다. 그리고 그것은 Honda Accord에서 아무것도 바꾸지 않을 것입니다.
왜 추상 클래스의 객체를 만들 수 없습니까?
왜냐하면 당신은 쇼룸에 들어가서 나에게 차를 주라고 말할 수 없기 때문입니다. 고유명사를 제공해야 합니다. 무슨 차? 아마 혼다 어코드가 아닐까 싶습니다. 그리고 그 때 판매 대리인이 당신에게 무언가를 줄 수 있습니다.
인터페이스의 개체를 만들 수 없는 이유는 무엇입니까? 쇼룸에 들어가서 음악 플레이어 계약을 하라고 할 수 없기 때문입니다. 도움이 되지 않습니다. 인터페이스는 단지 계약을 용이하게 하기 위해 소비자와 공급자 사이에 위치합니다. 계약서 사본으로 무엇을 하시겠습니까? 음악이 재생되지 않습니다.
인터페이스가 다중 상속을 허용하는 이유는 무엇입니까?
인터페이스는 상속되지 않습니다. 인터페이스가 구현됩니다. 인터페이스는 외부 세계와의 상호 작용을 위한 후보입니다. Honda Accord에는 연료 보급을 위한 인터페이스가 있습니다. 타이어에 공기를 주입하기 위한 인터페이스가 있습니다. 그리고 축구공을 부풀리는 데 사용되는 동일한 호스입니다. 따라서 새 코드는 다음과 같습니다.
abstract class Car { string color; int speed; } class HondaAccord : Car, IInflateAir, IRefueling { MusicPlayer musicPlayer; }
그리고 영어는 "Honda Accord is a Car that support the inflating Tire and refueling" 이라고 읽습니다.
출처 : http:www.stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo