Interfejs vs klasa abstrakcyjna (ogólne OO)

Może analogia: kiedy byłem w Siłach Powietrznych, poszedłem na szkolenie pilotów i zostałem pilotem USAF (US Air Force). W tym momencie nie miałem kwalifikacji do niczego latania i musiałem wziąć udział w szkoleniu na typ samolotu. Po uzyskaniu kwalifikacji byłem pilotem (klasa abstrakcyjna) i pilotem C-141 (Klasa betonowa). W jednym z moich zadań powierzono mi dodatkowe obowiązki: oficera bezpieczeństwa. Teraz nadal byłem pilotem i pilotem C-141, ale pełniłem również obowiązki oficera bezpieczeństwa (wdrożyłem ISafetyOfficer, więc do mów). Pilot nie musiał być oficerem bezpieczeństwa, inni też mogli to zrobić.

Wszyscy piloci USAF muszą przestrzegać pewnych przepisów dotyczących Sił Powietrznych, a wszyscy piloci C-141 (lub F-16 lub T-38) są pilotami USAF. Każdy może być oficerem bezpieczeństwa. Podsumowując:

• Pilot: klasa abstrakcyjna
• C-141 Pilot: klasa betonu
• Isafety Officer: interface

Dodana uwaga: to miała być analogia, która pomoże wyjaśnić pojęcie, a nie zalecenia dotyczące kodowania. Zobacz różne komentarze poniżej, dyskusja jest ciekawa.

Myślę, że odpowiedź, której szukają, to fundamentalna lub filozoficzna różnica.

Dziedziczenie klasy abstrakcyjnej jest używane, gdy klasa pochodna dzieli podstawowe właściwości i zachowanie klasy abstrakcyjnej. Rodzaj zachowania, które faktycznie definiuje klasę.

Z drugiej strony dziedziczenie interfejsu jest używane, gdy klasy dzielą zachowanie peryferyjne, które niekoniecznie definiują klasę pochodną.

Dla np. Samochód i ciężarówka dzielą się wiele podstawowych właściwości i zachowania klasy abstrakcyjnej samochodów, ale mają również pewne zachowania peryferyjne, takie jak generowanie spalin, które nawet klasy nie Samochodowe, takie jak wiertarki lub Powergeneratory dzielą i niekoniecznie definiują samochód lub ciężarówkę, więc samochód, ciężarówka, Wiertarka i PowerGenerator mogą dzielić ten sam interfejs IExhaust.

Krótkie: klasy abstrakcyjne są używane do modelowania hierarchii klas o podobnym wyglądzie (na przykład zwierzę może być klasą abstrakcyjną, a człowiek, lew, tygrys mogą być konkretnymi klasami pochodnymi)

I

Interface służy do komunikacji pomiędzy 2 podobnymi / nie podobnymi klasami, które nie dbają o Typ interfejsu implementującego klasy (np. wysokość może być właściwością interfejsu i może być zaimplementowana przez człowieka , budynek , drzewo. Nie nieważne, czy możesz jeść, pływać, umierać, czy cokolwiek.. liczy się tylko to, że trzeba mieć wysokość (implementacja w klasie)).

Istnieje kilka innych różnic -

Interfejsy nie mogą mieć żadnych konkretnych implementacji. Abstrakcyjne klasy bazowe mogą. Pozwala to na realizację konkretnych wdrożeń. Może to pozwolić abstrakcyjnej klasie bazowej na dostarczenie bardziej rygorystycznego kontraktu, w którym interfejs tak naprawdę opisuje tylko sposób użycia klasy. (Abstrakcyjna klasa bazowa może mieć nie-wirtualne elementy definiujące zachowanie, co daje większą kontrolę autorowi klasy bazowej.)

Więcej niż jeden interfejs może być zaimplementowany na klasie. Klasa może wywodzić się tylko z jednej abstrakcyjnej klasy bazowej. Pozwala to na hierarchię polimorficzną przy użyciu interfejsów, ale nie abstrakcyjnych klas bazowych. Pozwala to również na pseudo-multi-dziedziczenie przy użyciu interfejsów.

Abstrakcyjne klasy bazowe mogą być modyfikowane w v2 + bez łamania API. Zmiany w interfejsach są przełomowe.

[C#/. Net Specific] Interfejsy, w przeciwieństwie do abstrakcyjnych klas bazowych, mogą być stosowane do typów wartości (structs). Struktury nie mogą dziedziczyć z abstrakcyjnych klas bazowych. Pozwala to na stosowanie umów behawioralnych / wytycznych dotyczących użytkowania w odniesieniu do typów wartości.

Dziedziczenie
Rozważ samochód i autobus. Są to dwa różne pojazdy. Ale nadal mają wspólne właściwości, takie jak układ kierowniczy, hamulce, przekładnie, silnik itp.
Tak więc z koncepcją dziedziczenia można to przedstawić w następujący sposób ...

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;
}

To wszystko o dziedziczeniu. Używamy ich do klasyfikowania obiektów do prostszych form bazowych i ich dzieci, jak widzieliśmy powyżej.

Klasy Abstrakcyjne

Klasy abstrakcyjne to niekompletne obiekty. Aby to zrozumieć, rozważmy jeszcze raz analogię pojazdu.
Pojazd można prowadzić. Prawda? Ale różne pojazdy są napędzane na różne sposoby ... Na przykład, nie możesz prowadzić samochodu tak jak jeździsz rowerem.
Jak więc reprezentować funkcję napędu pojazdu? Trudniej jest sprawdzić, jaki to jest typ pojazdu i prowadzić go z własną funkcją; Można trzeba zmieniać klasę kierowcy raz po raz przy dodawaniu nowego typu pojazdu.
Tutaj pojawia się rola abstrakcyjnych klas i metod. Możesz zdefiniować metodę napędu jako abstrakcyjną, aby powiedzieć, że wszystkie dziedziczące dzieci muszą zaimplementować tę funkcję.
Więc jeśli zmodyfikujesz klasę pojazdu ...

//......Code of Vehicle Class
abstract public void drive();
//.....Code continues

Rower i samochód muszą również określić, jak go prowadzić. W przeciwnym razie kod nie zostanie skompilowany i zostanie wyrzucony błąd.
Krótko mówiąc.. klasa abstrakcyjna jest klasą częściowo niekompletną z niektórymi niepełnymi funkcjami, które dziedziczące dzieci muszą określić własne.

Interfejsy Interfejsy są całkowicie niekompletne. Nie mają żadnych właściwości. Wskazują tylko, że dziedziczące dzieci są w stanie coś zrobić ...
Załóżmy, że masz ze sobą różne rodzaje telefonów komórkowych. Każdy z nich ma różne sposoby wykonywania różnych funkcji; np. Producent telefonu określa, jak to zrobić. Tutaj telefony komórkowe mogą wybrać numer-to znaczy, że jest wybierany. Przedstawmy to jako interfejs.

public interface Dialable {
    public void dial(Number n);
}

Tutaj producent Wybierania określa sposób wybierania numeru. Musisz tylko podać numer do wybrania.

// 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);
}
.....

Używając interfejsów zamiast klas abstrakcyjnych, autor funkcji, która używa Dialable, nie musi martwić się o jej właściwości. Ex: czy ma ekran dotykowy lub dial pad, czy jest to stacjonarny telefon stacjonarny lub telefon komórkowy. Musisz tylko wiedzieć, czy jest wybierany; czy to odziedzicz (lub zaimplementuj) interfejs wybierany.

i co ważniejsze, jeśli pewnego dnia zmienisz Wybieranie na inne

......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

Możesz być pewien, że kod nadal działa idealnie, ponieważ funkcja, która korzysta z funkcji wybierania nie zależy (i nie może) od szczegółów innych niż te określone w interfejsie Wybierania. Obie implementują interfejs wybierany i to jest jedyna rzecz, na której funkcja dba.

Interfejsy są powszechnie używane przez deweloperów w celu zapewnienia interoperacyjności (używać zamiennie) między obiektami, o ile mają wspólną funkcję(tak jak można zmienić na telefon stacjonarny lub komórkowy, o ile wystarczy wybrać numer). W skrócie, interfejsy są znacznie prostszą wersją klas abstrakcyjnych, bez żadnych właściwości.
Zauważ również, że możesz zaimplementować(dziedziczyć) tyle interfejsów, ile chcesz, ale możesz rozszerzyć (dziedziczyć) tylko jedną klasę rodzica.

Więcej Informacji Streszczenie klasy vs Interfejsy

Jeśli uznasz java za język OOP, aby odpowiedzieć na to pytanie, Wydanie Java 8 powoduje, że część treści w powyższych odpowiedziach jest przestarzała. Teraz interfejs java może mieć domyślne metody z konkretną implementacją.

Oracle website dostarcza kluczowych różnic między klasami interface i abstract.

Rozważ użycie klas abstrakcyjnych, Jeśli:

1. chcesz podzielić się kodem pomiędzy kilka ściśle powiązanych klas.
2. spodziewasz się, że klasy, które rozciągają twoja klasa abstrakcyjna ma wiele typowych metod lub pól lub wymaga modyfikatorów dostępu innych niż publiczne(np. protected I private).
3. chcesz zadeklarować niestatyczne lub niekończące się pola.

Rozważ użycie interfejsów, Jeśli:

1. spodziewasz się, że niepowiązane klasy zaimplementują Twój interfejs. Na przykład wiele niepowiązanych obiektów może zaimplementować interfejs Serializable.
2. chcesz określić zachowanie określonego typu danych, ale nie zaniepokojony tym, kto realizuje jego zachowanie.
3. chcesz skorzystać z dziedziczenia wielokrotnego typu.

W prostych słowach, chciałbym użyć

interfejs: do realizacji umowy przez wiele niepowiązanych obiektów

klasa abstrakcyjna: aby zaimplementować to samo lub różne zachowanie między wieloma powiązanymi obiektami

Spójrz na przykład kodu, aby zrozumieć rzeczy w jasny sposób: Jak powinienem wyjaśniłeś różnicę między interfejsem a klasą abstrakcyjną?

Ankieterzy szczekają po dziwnym drzewie. Dla języków takich jak C# i Java Istnieje różnica, ale w innych językach, takich jak C++, nie ma. Teoria OO nie rozróżnia tych dwóch, a jedynie składnię języka.

Klasa abstrakcyjna jest klasą z implementacją i interfejsem (czyste metody wirtualne), które będą dziedziczone. Interfejsy na ogół nie mają żadnej implementacji, a jedynie czyste funkcje wirtualne.

W C# lub Javie klasa abstrakcyjna bez żadnych implementacja różni się od interfejsu tylko składnią używaną do dziedziczenia z niego i faktem, że można dziedziczyć tylko z jednego.

Implementując interfejsy, uzyskujesz kompozycję (relacje "has-a") zamiast dziedziczenia (relacje" is-a"). Jest to ważna zasada, o której należy pamiętać, jeśli chodzi o wzorce projektowe, w których należy użyć interfejsów, aby osiągnąć kompozycję zachowań zamiast dziedziczenia.

Wyjaśnię szczegóły dotyczące interfejsu i klasy abstrakcyjnej.jeśli znasz overview o interfejsie i klasie abstrakcyjnej, to pierwsze pytanie pojawia się w twoim umyśle, kiedy powinniśmy używać interfejsu, a kiedy powinniśmy używać klasy abstrakcyjnej. Więc proszę sprawdzić poniżej Wyjaśnienie interfejsu i klasy abstrakcyjnej.

1. Kiedy powinniśmy używać interfejsu?

   Jeśli nie wiesz o implementacji, po prostu mamy specyfikację wymagań, to idziemy z interfejsem

2. Kiedy powinniśmy używać klasy abstrakcyjnej?

   Jeśli znasz implementację, ale nie do końca (częściowo implementację) to wybieramy klasę Abstract.

   Interfejs

   Każda metoda domyślnie Public abstract oznacza, że interfejs jest w 100% czysty abstract.

   Abstract

   Może mieć metodę konkretną i metodę abstrakcyjną, co jest metodą konkretną, która ma implementację w klasie abstrakcyjnej, Klasa abstrakcyjna jest klasą deklarowaną jako abstrakcyjna-może zawierać metody abstrakcyjne lub nie.

   Interfejs

   Nie możemy zadeklarować interfejsu jako prywatnego, chronionego

   P. dlaczego nie deklarujemy interfejsu jako prywatnego i chronionego?

   Ponieważ domyślnie metoda interfejsu jest public abstract więc i dlatego nie deklarujemy interfejsu jako prywatnego i chronionego.

   Metoda interfejsu
   również nie możemy zadeklarować interfejsu jako prywatne, chronione, końcowe, statyczne, zsynchronizowane, natywne.....

   Podam powód: dlaczego nie deklarujemy metody zsynchronizowanej, ponieważ nie możemy utworzyć obiektu interfejsu i synchronize są prace na obiekcie Tak i son powód, że nie deklarujemy metody zsynchronizowanej Pojęcie Transient również nie ma zastosowania, ponieważ transient działa z synchronizacją.

   Abstract

   Z przyjemnością korzystamy z public, private final static.... oznacza brak ograniczeń zastosowanie w abstrakcji.

   Interfejs

   Zmienne są deklarowane w interfejsie jako domyślnie public static final, więc nie jesteśmy również deklarowanymi zmiennymi jako private, protected.

   Modyfikator zmienny nie ma również zastosowania w interfejsie, ponieważ zmienna interfejsu jest domyślnie publiczną statyczną zmienną końcową i końcową nie możesz zmienić wartości po przypisaniu wartości do zmiennej i po zadeklarowaniu zmiennej do interfejsu musisz przypisać zmienną. zmienna.

   A zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna zmienna na koniec z tego powodu nie używamy zmiennej volatile w interfejsie.

   Abstract

   Abstrakcyjna zmienna nie ma potrzeby deklarowania public static final.

Mam nadzieję, że ten artykuł jest przydatny.

Mówiąc koncepcyjnie, zachowując implementację specyficzną dla języka, Zasady, korzyści i osiągając dowolny cel programistyczny przy użyciu kogokolwiek lub obu, może lub nie może mieć kodu/danych/własności, bla bla, pojedynczych lub wielu dziedziczeń, wszystko na bok

1-klasa abstrakcyjna (lub czysta abstrakcja) jest przeznaczona do implementacji hierarchii. Jeśli obiekty biznesowe wyglądają strukturalnie podobnie, reprezentując relację rodzic-dziecko (hierarchia) tylko wtedy zostaną użyte klasy dziedziczenia / abstrakcyjne. Jeśli twój model biznesowy nie ma hierarchii, dziedziczenie nie powinno być używane (tutaj nie mówię o logice programowania, np. niektóre wzorce projektowe wymagają dziedziczenia). Koncepcyjnie, klasa abstrakcyjna jest metodą implementacji hierarchii modelu biznesowego w OOP, to nie ma nic wspólnego z interfejsami, w rzeczywistości porównywanie klasy abstrakcyjnej z interfejsem jest bez znaczenia, ponieważ oba są koncepcyjnie zupełnie różne rzeczy, jest pytany w wywiadach tylko, aby sprawdzić pojęcia, ponieważ wygląd oba zapewniają nieco taką samą funkcjonalność, gdy chodzi o implementację, a my programiści zwykle bardziej koncentrujemy się na kodowaniu. [Należy pamiętać, że abstrakcja różni się od klasy abstrakcyjnej].

2-Interfejs jest kontraktem, kompletną funkcjonalnością biznesową reprezentowaną przez jeden lub więcej zestawów funkcji. Dlatego jest on wdrażany, a nie dziedziczony. Obiekt biznesowy (część hierarchii lub nie) może mieć dowolną liczbę kompletnych funkcji biznesowych. Ma nic wspólnego z klasami abstrakcyjnymi nie oznacza dziedziczenia w ogóle. Na przykład człowiek może biegać, słoń może biegać, ptak może biegać i tak dalej, wszystkie te obiekty o różnej hierarchii implementowałyby interfejs RUN lub EAT lub SPEAK. Nie wdawaj się w implementację, ponieważ możesz zaimplementować ją jako abstrakcyjne klasy dla każdego typu implementującego te interfejsy. Obiekt dowolnej hierarchii może mieć funkcjonalność (interfejs), która nie ma nic wspólnego z jego hierarchią.

I podobnie, Czyste klasy abstrakcyjne nie mają na celu unieważnienia interfejsów, ale interfejs jest funkcjonalnością, którą obiekt może wykonać (poprzez funkcje tego interfejsu), A klasa abstrakcyjna reprezentuje rodzica hierarchii do wytwarzania dzieci o strukturze rdzenia (właściwość+funkcjonalność) rodzica

Kiedy zostaniesz zapytany o różnicę, jest to w rzeczywistości różnica pojęciowa, a nie różnice w implementacji specyficznej dla danego języka, chyba że wyraźnie o to poproszono.

Wydaje mi się, że obaj rozmówcy oczekiwali jednej linii prostej różnicy między tymi dwoma i kiedy ci się nie udało, próbowali doprowadzić cię do tej różnicy, wdrażając jedną jako drugą

Co by było, gdybyś miał abstrakcyjną klasę z tylko abstrakcyjnymi metodami?

Dla. Net,

Twoja odpowiedź na drugiego rozmówcę jest również odpowiedzią na pierwszego... Klasy abstrakcyjne mogą mieć implementację, a stan, interfejsy nie mogą...

EDIT: z innej uwagi, nie użyłbym nawet wyrażenia "subclass" (lub wyrażenia "inheritance") do opisania klas, które są "zdefiniowane do implementacji" interfejsu. Dla mnie interfejs jest definicją kontraktu, do którego klasa musi być zgodna, jeśli została zdefiniowana jako "implementacja" tego interfejsu. Tak. niczego nie odziedziczy... Musisz wszystko dodać sam, wyraźnie.

Myślę, że nie spodobała im się Twoja odpowiedź, ponieważ podałeś różnice techniczne zamiast projektowych. To pytanie jest dla mnie jak troll. W rzeczywistości interfejsy i abstrakcyjne klasy mają zupełnie inną naturę, więc nie można ich naprawdę porównać. Przedstawię wam moją wizję, jaka jest rola interfejsu, a jaka jest rola abstrakcyjnej klasy.

Interfejs: jest używany do zapewnienia kontraktów i tworzenia niskiego sprzężenia między klasami, aby mieć bardziej łatwa w utrzymaniu, skalowalna i testowalna aplikacja.

Klasa abstrakcyjna: jest używana tylko do faktoryzacji kodu pomiędzy klasami o tej samej odpowiedzialności. Zauważ, że jest to główny powód, dla którego dziedziczenie wielokrotne jest złą rzeczą w OOP, ponieważ klasa nie powinna obsługiwać wielu responsability (zamiast tego użyj composition ).

Więc interfejsy mają rzeczywistą rolę architektoniczną, podczas gdy klasy abstrakcyjne są prawie tylko szczegółem implementacji (jeśli go używasz oczywiście poprawnie).

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?" 

Docs wyraźnie mówi, że jeśli klasa abstrakcyjna zawiera tylko deklaracje abstrakcyjnych metod, powinna być zadeklarowana jako interfejs.

An another interviewer asked me what if you had a Public variable inside
the interface, how would that be different than in Abstract Class?

Zmienne w interfejsach są domyślnie publiczne statyczne i końcowe. Pytanie może być w ramce jak co, jeśli wszystkie zmienne w klasie abstrakcyjnej są publiczne? Cóż, nadal mogą być niestatyczne i nie końcowe w przeciwieństwie do zmiennych w interfejsach.

Na koniec dodałbym jeszcze jeden punkt do wyżej wymienionych-klasy abstrakcyjne nadal są klasami i należą do jednego drzewa dziedziczenia, podczas gdy interfejsy mogą być obecne w wielu dziedziczeniach.

Różnica między interfejsem Javy a klasą abstrakcyjną

1. Główną różnicą jest to, że metody interfejsu Java są niejawnie abstrakcyjne i nie mogą mieć implementacji. Klasa abstrakcyjna Java może posiadać metody instancji implementujące domyślne zachowanie.

2. Zmienne deklarowane w interfejsie Java są domyślnie ostateczne. Klasa abstrakcyjna może zawierać zmienne niekończące się.

3. Elementy interfejsu Java są domyślnie publiczne. Klasa abstrakcyjna Java może mają zwykłe smaki członków klasy, takich jak prywatne, chronione, itp..

4. Interfejs Java powinien być zaimplementowany za pomocą słowa kluczowego "implements"; klasa abstrakcyjna Java powinna być rozszerzona za pomocą słowa kluczowego "extends".

5. Interfejs może rozszerzyć tylko inny interfejs Java, klasa abstrakcyjna może rozszerzyć inną klasę Java i zaimplementować wiele interfejsów Java.

6. Klasa Java może zaimplementować wiele interfejsów, ale może rozszerzyć tylko jeden abstrakcyjny klasy.

7. Interfejs jest absolutnie abstrakcyjny i nie można utworzyć instancji; klasy abstrakcyjnej Javy również nie można utworzyć instancji, ale można ją wywołać, jeśli istnieje funkcja main ().

8. W porównaniu z klasami abstrakcyjnymi Javy, interfejsy Javy są powolne, ponieważ wymagają dodatkowej indirection.

1. Interfejs:
   • nie implementujemy (ani nie definiujemy) metod, robimy to w klasach pochodnych.
   • nie deklarujemy zmiennych członkowskich w interfejsach.
   • interfejsy wyrażają relację HAS-A. Oznacza to, że są maską przedmiotów.
2. klasa abstrakcyjna:
   • Możemy zadeklarować i zdefiniować metody w klasie abstrakcyjnej.
   • ukrywamy jej konstruktory. Oznacza to, że nie istnieje żaden obiekt utworzony bezpośrednio z niego.
   • klasa abstrakcyjna może posiadać członka zmienne.
   • klasy pochodne dziedziczą do klasy abstrakcyjnej, co oznacza, że obiekty z klas pochodnych nie są maskowane, dziedziczą do klasy abstrakcyjnej. Relacja w tym przypadku jest-A.

Skopiowany z CLR przez C# przez Jeffreya Richtera...

Często słyszę pytanie: "Czy powinienem zaprojektować typ bazowy czy interfejs?"Odpowiedź nie zawsze jest klarowna.

Oto kilka wskazówek, które mogą Ci pomóc:

■■ relacja IS-a vs. CAN-DO Typ może dziedziczyć tylko jedną implementację. Jeśli pochodna type can 't claim an is-a relation with the base type, don' t use a base type; use an interface. Interfejsy implikują relację CAN-DO. Jeśli funkcja CAN-DO wydaje się należeć w przypadku różnych typów obiektów użyj interfejsu. Na przykład typ może konwertować swoje instancje do innego typu (IConvertible), Typ może serializować samą instancję (ISerializable), itd. Należy pamiętać, że typy wartości muszą pochodzić z systemu.ValueType, a zatem nie mogą być pochodną dowolnej klasy bazowej. W takim przypadku musisz użyć relacji CAN-DO i zdefiniuj interfejs.

■■ łatwość użycia ogólnie łatwiej jest ci jako programiście zdefiniować nowy typ wywodzący się z typ bazowy niż zaimplementować wszystkie metody interfejsu. Typ podstawy może zapewnić duża funkcjonalność, więc Typ Pochodny prawdopodobnie wymaga jedynie stosunkowo niewielkich modyfikacji jego zachowania. Jeśli dostarczysz interfejs, nowy typ musi zaimplementować wszystkie elementy.

■■ spójna implementacja bez względu na to, jak dobrze udokumentowana jest umowa interfejsu, jest bardzo mało prawdopodobne, że każdy będzie realizować umowę w 100 procent prawidłowo. W rzeczywistości, COM dlatego niektóre obiekty COM działają poprawnie tylko z Microsoft Word lub z Windows Internet Explorer. Poprzez dostarczenie typu bazowego z dobrym domyślnej implementacji, zaczynasz używać typu, który działa i jest dobrze przetestowany; możesz wtedy Modyfikuj części, które wymagają modyfikacji.

■■ wersjonowanie jeśli dodasz metodę do typu podstawowego, Typ Pochodny dziedziczy nową metodę, zaczynasz używać typu, który działa, a kod źródłowy użytkownika nie ma nawet do przekompilowania. Dodanie nowego członka do interfejsu wymusza zmianę dziedziczenia interfejsu jego kod źródłowy i przekompilować.

Interfejs : powinien być stosowany, jeśli chcesz zasugerować regułę dotyczącą składników, które mogą lub nie mogą być powiązane ze sobą

Plusy:

1. pozwala na wielokrotne dziedziczenie
2. zapewnia abstrakcję, nie ujawniając, jaki dokładnie rodzaj obiektu jest używany w kontekście
3. zapewnia spójność poprzez konkretne podpisanie umowy

Wady:

1. musi realizować wszystkie umowy defined
2. nie można mieć zmiennych ani delegatów
3. raz zdefiniowane nie mogą być zmieniane bez łamania wszystkich klas

klasa abstrakcyjna : powinno być używane tam, gdzie chcemy mieć jakieś podstawowe lub domyślne zachowanie lub implementację Dla komponentów powiązanych ze sobą

Plusy:

1. szybciej niż interfejs
2. ma elastyczność w implementacji (można ją wdrożyć w całości lub częściowo)
3. Może być łatwo zmieniono bez łamania klas pochodnych

Wady:

1. nie można utworzyć instancji
2. nie obsługuje dziedziczenia wielokrotnego

Interfejs definiuje umowę na usługę lub zestaw usług. Zapewniają one polimorfizm w sposób horyzontalny, ponieważ dwie zupełnie niepowiązane ze sobą klasy mogą zaimplementować ten sam interfejs, ale mogą być używane zamiennie jako parametr typu interfejsu, który implementują, ponieważ obie klasy obiecały spełniać zestaw usług zdefiniowanych przez interfejs. Interfejsy nie dostarczają żadnych szczegółów implementacji.

Klasa abstrakcyjna definiuje strukturę bazową dla swoich podklas oraz opcjonalnie częściowa realizacja. Klasy abstrakcyjne zapewniają polimorfizm w sposób pionowy, ale Kierunkowy, ponieważ każda klasa, która dziedziczy klasę abstrakcyjną, może być traktowana jako instancja tej klasy abstrakcyjnej, ale nie odwrotnie. Klasy abstrakcyjne mogą i często zawierają szczegóły implementacji, ale nie mogą być tworzone samodzielnie - tylko ich podklasy mogą być "nowe".

C# pozwala również na dziedziczenie interfejsu.

Większość odpowiedzi skupia się naróżnicy technicznej między klasą abstrakcyjną a interfejsem, ale ponieważ technicznie, interfejs jest w zasadzie rodzajem klasy abstrakcyjnej (bez żadnych danych lub implementacji), myślę, żekonceptualna różnica jest o wiele bardziej interesująca, i to może być to, czego szukają ankieterzy.

An Interface jest umową . Określa ona: "tak będziemy ze sobą rozmawiać". Nie może mieć żadnej implementacji ponieważ to nie powinno mieć jakąkolwiek implementację. To kontrakt. To jak pliki nagłówkowe .h W C.

Klasa abstrakcyjna jest niekompletną implementacją . Klasa może zaimplementować interfejs, a klasa abstrakcyjna nie musi go całkowicie zaimplementować. Abstrakcyjna klasa bez żadnej implementacji jest bezużyteczna, ale całkowicie legalna.

W zasadzie każda klasa, abstrakcyjna lub nie, jest o tym, czym jest , podczas gdy interfejs jest o jak go używać . Na przykład: Animal może być abstrakcyjną klasą realizującą pewne podstawowe funkcje metaboliczne i określającą abstrakcyjne metody oddychania i poruszania się bez podania implementacji, ponieważ nie ma pojęcia, czy powinna oddychać przez skrzela czy płuca, czy też lata, pływa, chodzi czy czołga. Mount, z drugiej strony, może być interfejs, który określa, że można jeździć zwierzę, nie wiedząc, co to za zwierzę (lub czy jest to zwierzę w ogóle!).

Fakt, że za kulisami interfejs jest w zasadzie klasą abstrakcyjną z tylko abstrakcyjnymi metodami, nie ma znaczenia. Koncepcyjnie pełnią zupełnie inne role.

Różnica klas abstrakcyjnych i interfejsów:

1. klasa abstrakcyjna może mieć metody abstrakcyjne i nieabstraktowe, a interfejs może mieć tylko metody abstrakcyjne.
2. klasa abstrakcyjna nie obsługuje dziedziczenia wielokrotnego, A Interfejs obsługuje dziedziczenie wielokrotne.
3. klasa abstrakcyjna może mieć zmienne końcowe, niestatyczne, statyczne i niestatyczne, a interfejs ma tylko zmienne statyczne i końcowe.
4. klasa abstrakcyjna może mieć metody statyczne, metodę główną i konstruktor i interfejs nie mogą mieć metod statycznych, metody głównej lub konstruktora.
5. klasa abstrakcyjna może zapewnić implementację interfejsu, a interfejs nie może zapewnić implementacji klasy abstrakcyjnej.
6. słowo kluczowe abstract jest używane do deklarowania klasy abstrakcyjnej, a słowo kluczowe interface jest używane do deklarowania interfejsu.
7. klasa abstrakcyjna osiąga abstrakcję częściową (0 do 100%), ponieważ istnieją metody nieabstraktowe również w klasie abstrakcyjnej, podczas gdy interfejs osiąga w pełni abstrakcja (100%).

Jak mogłeś mieć wiedzę teoretyczną od ekspertów, nie spędzam wiele słów na powtarzaniu tych wszystkich tutaj, raczej pozwól mi wyjaśnić prostym przykładem, gdzie możemy użyć / nie możemy użyć Interface i Abstract class.

Rozważ, że projektujesz aplikację do listy wszystkich funkcji samochodów. W różnych punktach potrzebujesz dziedziczenia wspólnego, ponieważ niektóre z właściwości, takich jak Cyfrowymfuelmeter, Klimatyzacja, regulacja siedzeń, itp są wspólne dla wszystkich samochodów. Podobnie, potrzebujemy dziedziczenie tylko dla niektórych klas, ponieważ niektóre właściwości, takie jak układ hamulcowy (ABS, EBD)mają zastosowanie tylko dla niektórych samochodów.

Poniższa klasa działa jako podstawowa klasa dla wszystkich samochodów:

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";
    }
}

Rozważmy, że mamy osobną klasę dla każdego samochodu.

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        
}

Rozważmy, że potrzebujemy metody dziedziczenia technologii hamowania dla samochodów Verna i Cruze (Nie dotyczy Alto). Chociaż oba wykorzystują technologię hamowania, "technologia" jest inna. Tworzymy więc klasa abstrakcyjna, w której metoda zostanie zadeklarowana jako abstrakcyjna i powinna być zaimplementowana w jej klasach potomnych.

public abstract class Brake
{
    public abstract string GetBrakeTechnology();
}

Teraz staramy się dziedziczyć z tej abstrakcyjnej klasy, A Typ układu hamulcowego jest zaimplementowany w Vernie i 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";
    }         
}

Widzisz problem w powyższych dwóch klasach? Dziedziczą z wielu klas, które C#.Net nie pozwala, mimo że metoda jest zaimplementowana w dzieciach. Tutaj pojawia się potrzeba interfejsu.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

I implementacja jest podana poniżej:

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";
   }        
}

Teraz Verna i Cruze mogą osiągnąć wiele dziedziczeń za pomocą własnych technologii hamowania za pomocą interfejsu.

Interfejsy są lekkim sposobem wymuszania określonego zachowania. To jeden ze sposobów na myślenie.

1) interfejs może być postrzegany jako czysta klasa abstrakcyjna, jest taki sam, ale mimo to, nie jest to to samo zaimplementować interfejs i dziedziczenie z klasy abstrakcyjnej. Kiedy dziedziczysz z tej czystej abstrakcyjnej klasy, definiujesz hierarchię - > dziedziczenie, jeśli zaimplementujesz interfejs, nie jesteś, i możesz zaimplementować tyle interfejsów, ile chcesz, ale możesz dziedziczyć tylko z jednej klasy.

2) można zdefiniować właściwość w interfejsie, więc klasa, która implementuje interfejs musi mieć tę właściwość.

Na przykład:

  public interface IVariable
  {
      string name {get; set;}
  }

Klasa implementująca ten interfejs musi mieć taką właściwość.

Choć to pytanie jest dość stare, chciałbym dodać jeszcze jeden punkt na korzyść interfejsów:

Interfejsy mogą być wstrzykiwane za pomocą dowolnych narzędzi do iniekcji zależności, gdzie jako abstrakcyjna klasa iniekcji jest obsługiwana przez bardzo niewielu.

Odpowiedź na drugie pytanie: public zmienna zdefiniowana w interface jest domyślnie static final, podczas gdy zmienna public w klasie abstract jest zmienną instancyjną.

Z kolejna moja odpowiedź , głównie zajmująca się tym, kiedy użyć jednego kontra drugiego:

Z mojego doświadczenia wynika, że interfejsy są najlepsze używane, gdy masz kilka klas które każdy musi odpowiedzieć na to samo metoda lub metody, aby mogły być używany zamiennie przez inny kod które zostaną napisane przeciwko tym wspólny interfejs klas. The best korzystanie z interfejsu jest wtedy, gdy protokół jest ważny, ale logika podstawowa może być inna dla każda klasa. Gdybyś inaczej był powielanie logiki, rozważenie abstrakcji klasy lub standardowe dziedziczenie klas zamiast tego.

Typy interfejsów a abstrakcyjne klasy bazowe

Zaadaptowane z Pro C# 5.0 i.NET 4.5 Framework książki.

Typ interfejsu może wydawać się bardzo podobny do abstrakcyjnej klasy bazowej. Przypomnienie że gdy klasa jest oznaczona jako abstrakcyjna, może zdefiniować dowolną liczbę elementów abstrakcyjnych, aby zapewnić interfejs polimorficzny do wszystkich typów pochodnych. Jednak nawet wtedy, gdy klasa definiuje zbiór abstrakcji członków, można również dowolnie definiować dowolną liczbę konstruktorów, pole danych, członkowie nonabstract (z implementacja), i tak dalej. Interfejsy, z drugiej strony, zawierają tylko abstrakcyjne definicje członów. Interfejs polimorficzny ustanowiony przez abstrakcyjną klasę nadrzędną cierpi na jedno główne ograniczenie tylko typy pochodne wspierają elementy zdefiniowane przez abstrakcyjny rodzic. Jednak w większych Systemów Oprogramowania, bardzo często rozwija się wiele hierarchii klas, które nie mają wspólnego rodzica poza systemem.Obiekt. Biorąc pod uwagę, że elementy abstrakcyjne w abstrakcie klasa bazowa dotyczy tylko pochodnych typy, nie mamy możliwości skonfigurowania typów w różnych hierarchiach, aby obsługiwały ten sam polimorficzny interfejs. Na przykład, załóżmy, że zdefiniowałeś następującą klasę abstrakcyjną:

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();
}

Biorąc pod uwagę tę definicję, tylko członkowie rozszerzający CloneableType mogą wspierać klon() metoda. Jeśli utworzysz nowy zestaw klas, które nie rozszerzają tej klasy bazowej, nie możesz tego uzyskać interfejs polimorficzny. Można również przypomnieć, że C# nie obsługuje wielokrotne dziedziczenie klas. Dlatego, jeśli chciałeś stworzyć minivana, który jest-samochodem i jest-typem CloneableType, nie jesteś w stanie tego zrobić: {]}

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

Jak można się domyślić, typy interfejsów przychodzą na ratunek. Po zdefiniowaniu interfejsu może być zaimplementowane przez dowolną klasę lub strukturę, w dowolnej hierarchii, w dowolnej przestrzeni nazw lub w dowolnym zestawie (napisane w dowolnym języku programowania. NET). Jak widać, interfejsy są wysoce polimorficzne. Rozważ standardowy interfejs. NET o nazwie ICloneable, zdefiniowany w przestrzeni nazw systemu. To interfejs definiuje pojedynczą metodę o nazwie Clone ():

public interface ICloneable
{
object Clone();
}

Z Perspektywy Kodowania

Interfejs może zastąpić klasę abstrakcyjną, jeśli klasa abstrakcyjna ma tylko metody abstrakcyjne. W przeciwnym razie zmiana klasy abstrakcyjnej na interfejs oznacza, że stracisz możliwość ponownego użycia kodu, który zapewnia dziedziczenie.

Z Perspektywy Projektu

Zachowaj ją jako klasę abstrakcyjną, jeśli jest relacją" jest " i potrzebujesz podzbioru lub całej funkcjonalności. Zachowaj go jako interfejs, jeśli jest to związek "powinien zrobić".

Decide czego potrzebujesz: tylko egzekwowanie zasad lub ponowne użycie kodu i Polityka.

Na pewno ważne jest, aby zrozumieć zachowanie interfejsu i klasy abstrakcyjnej w OOP( i jak języki sobie z nimi radzą), ale myślę, że ważne jest również, aby zrozumieć, co dokładnie oznacza każdy termin. Czy możesz sobie wyobrazić, że polecenie if nie działa dokładnie tak jak znaczenie tego terminu? Ponadto, w rzeczywistości niektóre języki zmniejszają, jeszcze bardziej, różnice między interfejsem a abstrakcją... jeśli przypadkiem któregoś dnia te dwa terminy działają niemal identycznie, to przynajmniej możesz zdefiniować siebie gdzie (i dlaczego) należy użyć któregokolwiek z nich.

Jeśli czytasz niektóre słowniki i inne czcionki, Możesz znaleźć różne znaczenia dla tego samego terminu, ale z pewnymi wspólnymi definicjami. Myślę, że te dwa znaczenia, które znalazłem w tej stronie są naprawdę, naprawdę dobre i odpowiednie.

Interfejs:

Rzecz lub okoliczność, która umożliwia efektywne koordynowanie oddzielnych i czasem niekompatybilnych elementów.

Streszczenie:

Coś, co koncentruje w sobie podstawowe cechy czegoś bardziej rozległego lub bardziej ogólnego, lub kilku rzeczy; esencji.

Przykład:

Twój model samochodu to XYZ, który jest gatunku ABC, więc jest to konkretny samochód, konkretna instancja samochodu. Samochód nie jest prawdziwym obiektem. W rzeczywistości jest to abstrakcyjny zestaw standardów (cech) do stworzenia określonego obiektu. Krótko mówiąc, samochód jest klasa abstrakcyjna , to jest"coś, co koncentruje w sobie podstawowe cechy wszystkiego, co bardziej rozległe lub bardziej ogólne"{37]}.

W widoku obiektowym nie powinno być deklarowane jako klasa, ponieważ nie ma konkretnego paliwa dla konkretnego gatunku samochodu. Chociaż twój samochód może zaakceptować paliwo klasy abstrakcyjnej lub VehicularFuel, musisz pamiętać, że tylko niektóre z istniejącego paliwa samochodowego spełniają specyfikację, te, które realizują wymagania w instrukcji obsługi samochodu. Krótko mówiąc, powinni zaimplementować interfejs ABCGenreFuel, które "... umożliwia efektywne koordynowanie elementów oddzielnych, a czasem niekompatybilnych " .

Dodatek

Ponadto, myślę, że należy pamiętać o znaczeniu terminu Klasa, który jest (z tej samej strony wcześniej wspomniano):

Klasa:

Liczba osób lub rzeczy uważanych za tworzące grupę ze względu na wspólne cechy, cechy, cechy lub cechy; rodzaj;

W ten sposób klasa (lub klasa abstrakcyjna) powinna nie reprezentują tylko wspólnych atrybutów (jak interfejs), ale jakąś grupę ze wspólnymi atrybutami. Interfejs nie musi reprezentować jakiegoś rodzaju. Musi reprezentować wspólne atrybuty. W ten sposób myślę, że klasy I klasy abstrakcyjne mogą być używane do reprezentowania rzeczy, które nie powinny często zmieniać swoich aspektów, jak człowiek jest ssakiem, ponieważ reprezentuje pewne rodzaje. Rodzaje nie powinny zmieniać się tak często.