Wat is het verschil tussen een interface en een abstracte klasse?

Wat is precies het verschil tussen een interface en een abstracte klasse?


Antwoord 1, autoriteit 100%

Interfaces

Een interface is een contract: de persoon die de interface schrijft, zegt: “hey, ik accepteer dat dingen er zo uitzien“, en de persoon die de interface gebruikt, zegt: “OK, de les die ik schrijf ziet er zo uit“.

Een interface is een lege schil. Er zijn alleen de handtekeningen van de methoden, wat inhoudt dat de methoden geen body hebben. De interface kan niets. Het is maar een patroon.

Bijvoorbeeld (pseudocode):

// I say all motor vehicles should look like this:
interface MotorVehicle
{
    void run();
    int getFuel();
}
// My team mate complies and writes vehicle looking that way
class Car implements MotorVehicle
{
    int fuel;
    void run()
    {
        print("Wrroooooooom");
    }
    int getFuel()
    {
        return this.fuel;
    }
}

Het implementeren van een interface verbruikt heel weinig CPU, omdat het geen klasse is, maar een aantal namen, en daarom is er geen dure look-up te doen. Het is geweldig als het er toe doet, zoals in embedded apparaten.


Abstracte lessen

Abstracte klassen zijn, in tegenstelling tot interfaces, klassen. Ze zijn duurder in gebruik, omdat je moet opzoeken wanneer je ze erft.

Abstracte klassen lijken veel op interfaces, maar ze hebben iets meer: ​​je kunt er gedrag voor definiëren. Het gaat meer over een persoon die zegt: “deze lessen zouden er zo uit moeten zien, en dat hebben ze gemeen, dus vul de lege plekken in!“.

Bijvoorbeeld:

// I say all motor vehicles should look like this:
abstract class MotorVehicle
{
    int fuel;
    // They ALL have fuel, so lets implement this for everybody.
    int getFuel()
    {
         return this.fuel;
    }
    // That can be very different, force them to provide their
    // own implementation.
    abstract void run();
}
// My teammate complies and writes vehicle looking that way
class Car extends MotorVehicle
{
    void run()
    {
        print("Wrroooooooom");
    }
}

Implementatie

Hoewel abstracte klassen en interfaces verschillende concepten zouden moeten zijn, maken de implementaties die bewering soms onwaar. Soms zijn ze niet eens wat je denkt dat ze zijn.

In Java wordt deze regel streng gehandhaafd, terwijl in PHP interfaces abstracte klassen zijn zonder gedeclareerde methode.

In Python zijn abstracte klassen meer een programmeertruc die je uit de ABC-module kunt halen en die eigenlijk metaklassen gebruikt, en dus klassen. En interfaces hebben meer te maken met het typen van eenden in deze taal en het is een mix tussen conventies en speciale methoden die descriptors aanroepen (de __method__-methoden).

Zoals gebruikelijk bij programmeren, is er theorie, praktijk en praktijk in een andere taal 🙂


Antwoord 2, autoriteit 39%

De belangrijkste technische verschillen tussen een abstracte les en een interface zijn:

  • Abstracte klassen kunnen constanten, leden, methodestubs (methoden zonder hoofdtekst) en gedefinieerde methoden hebben, terwijl interfaces alleen constanten en kunnen hebben methodenstubs.

  • Methoden en leden van een abstracte klasse kunnen worden gedefinieerd met elke zichtbaarheid, terwijl alle methoden van een interface moeten worden gedefinieerd als public (ze zijn openbaar gedefinieerd standaard).

  • Bij het erven van een abstracte klasse, moet een concrete onderliggende klasse de abstracte methoden definiëren, terwijl een abstracte klasse een andere abstracte klasse en abstracte methoden kan uitbreiden van de bovenliggende klasse hoeft niet te worden gedefinieerd.

  • Evenzo is een interface die een andere interface uitbreidt niet verantwoordelijk voor het implementeren van methoden van de bovenliggende interface. Dit komt omdat interfaces geen enkele implementatie kunnen definiëren.

  • Een onderliggende klasse kan slechts een enkele klasse uitbreiden (abstract of concreet), terwijl een interface kan uitbreiden of een klasse meerdere andere interfaces kan implementeren.

  • Een onderliggende klasse kan abstracte methoden definiëren met dezelfde of minder beperkende zichtbaarheid, terwijl een klasse die een interface implementeert de methoden moet definiëren met exact dezelfde zichtbaarheid (openbaar).


Antwoord 3, autoriteit 7%

Een interface bevat alleen de definitie/handtekening van functionaliteit, en als we een aantal gemeenschappelijke functionaliteiten hebben, evenals gemeenschappelijke handtekeningen, dan moeten we een abstracte klasse gebruiken. Door een abstracte klasse te gebruiken, kunnen we zowel gedrag als functionaliteit tegelijkertijd bieden. Een andere ontwikkelaar die de abstracte klasse erft, kan deze functionaliteit gemakkelijk gebruiken, omdat ze alleen de lege plekken hoeven in te vullen.

voer hier de afbeeldingsbeschrijving in
Genomen van:

http://www.dotnetbull.com/ 2011/11/difference-between-abstract-class-and.html

http://www. dotnetbull.com/2011/11/what-is-abstract-class-in-c-net.html
http://www.dotnetbull.com/2011 /11/wat-is-interface-in-c-net.html


Antwoord 4, autoriteit 3%

Een uitleg vindt u hier: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter -Patroon.htm

Een abstracte klasse is een klasse die is
slechts gedeeltelijk uitgevoerd door de
programmeur. Het kan een of meer bevatten:
abstracte methoden. Een abstracte methode
is gewoon een functiedefinitie die:
dient om de programmeur te vertellen dat de
methode moet worden geïmplementeerd in een kind
klas.

Een interface lijkt op een abstract
klas; inderdaad interfaces bezetten de
dezelfde naamruimte als klassen en abstract
klassen. Om die reden kun je niet
definieer een interface met dezelfde naam
als een klas. Een interface is een volledig
abstracte klasse; geen van zijn methoden
zijn geïmplementeerd en in plaats van een klasse
sub-classificatie ervan, er wordt gezegd dat
implementeer die interface.

Hoe dan ook, ik vind deze uitleg van interfaces enigszins verwarrend. Een meer gebruikelijke definitie is: Een interface definieert een contract waaraan implementatieklassen moeten voldoen. Een interfacedefinitie bestaat uit handtekeningen van openbare leden, zonder enige implementatiecode.


Antwoord 5, autoriteit 2%

Ik wil de verschillen niet benadrukken, die al in veel antwoorden zijn gezegd (met betrekking tot openbare statische definitieve modifiers voor variabelen in interface en ondersteuning voor beschermde, privémethoden in abstracte klassen)

In eenvoudige bewoordingen zou ik willen zeggen:

interface: om een ​​contract te implementeren door meerdere niet-gerelateerde objecten

abstracte klasse: om hetzelfde of ander gedrag te implementeren bij meerdere gerelateerde objecten

Van de Oracle documentatie

Overweeg het gebruik van abstracte klassen als:

  1. Je wilt code delen met verschillende nauw verwante klassen.
  2. U verwacht dat klassen die uw abstracte klasse uitbreiden, veel gemeenschappelijke methoden of velden hebben, of andere toegangsmodifiers dan openbaar (zoals beveiligd en privé) vereisen.
  3. U wilt niet-statische of niet-definitieve velden declareren.

Overweeg het gebruik van interfaces als:

  1. Je verwacht dat niet-gerelateerde klassen je interface zouden implementeren. Veel niet-gerelateerde objecten kunnen bijvoorbeeld een Serializable-interface implementeren.
  2. U wilt het gedrag van een bepaald gegevenstype specificeren, maar u maakt zich geen zorgen over wie het gedrag implementeert.
  3. U wilt profiteren van meerdere typen overerving.

abstracte klasse vestigt “is een” relatie met concrete klassen. interface biedt “heeft een” mogelijkheid voor klassen.

Als u op zoek bent naar Java als programmeertaal, volgen hier nog een paar updates:

Java 8 heeft de kloof tussen interface en abstract klassen tot op zekere hoogte verkleind door een default methode te bieden. Een interface heeft geen implementatie voor een methode is nu niet meer geldig.

Raadpleeg deze pagina van deze documentatie voor meer informatie.

Bekijk deze SE-vraag voor codevoorbeelden om het beter te begrijpen.

Hoe had ik het verschil tussen een interface en een abstracte les moeten uitleggen?


Antwoord 6, autoriteit 2%

Enkele belangrijke verschillen:

In de vorm van een tabel:

Verschil

Als verklaard door Joe van javapapers:

1.Het belangrijkste verschil is dat methoden van een Java-interface impliciet abstract zijn en geen implementaties kunnen hebben. Een Java-abstracte klasse kan
instantiemethoden hebben die een standaardgedrag implementeren.

2.Variabelen die in een Java-interface zijn gedeclareerd, zijn standaard definitief. Een abstracte klasse kan niet-finale variabelen bevatten.

3.De leden van een Java-interface zijn standaard openbaar. Een Java-abstracte klasse kan de gebruikelijke smaken van klasseleden hebben, zoals privé,
beschermd, enz..

4.Java-interface moet worden geïmplementeerd met het trefwoord implements ; Een Java-abstracte klasse moet worden uitgebreid met het trefwoord extends .

5.Een interface kan alleen een andere Java-interface uitbreiden, een abstracte klasse kan een andere Java-klasse uitbreiden en meerdere Java implementeren
interfaces.

6.Een Java-klasse kan meerdere interfaces implementeren, maar kan slechts één abstracte klasse uitbreiden.

7.Interface is absoluut abstract en kan niet worden geïnstantieerd; Een Java-abstracte klasse kan ook niet worden geïnstantieerd, maar kan worden aangeroepen als a
main() bestaat.

8.In vergelijking met Java-abstracte klassen, zijn Java-interfaces traag omdat het extra indirectheid vereist.


Antwoord 7

Het belangrijkste punt is dat:

  • Abstract is objectgeoriënteerd. Het biedt de basisgegevens die een ‘object’ zou moeten hebben en/of functies die het zou moeten kunnen doen. Het gaat om de basiskenmerken van het object: wat het heeft en wat het kan. Vandaar dat objecten die erven van dezelfde abstracte klasse de basiskenmerken delen (veralgemening).
  • Interface is op functionaliteit gericht. Het definieert functionaliteiten die een object zou moeten hebben. Ongeacht welk object het is, zolang het deze functionaliteiten kan doen, die zijn gedefinieerd in de interface, is het prima. Het negeert al het andere. Een object/klasse kan meerdere (groepen van) functionaliteiten bevatten; daarom is het voor een klasse mogelijk om meerdere interfaces te implementeren.

Antwoord 8

Als u polymorf gedrag in een overervingshiërarchie wilt bieden, gebruikt u abstracte klassen.

Als je polymorf gedrag wilt voor klassen die totaal niets met elkaar te maken hebben, gebruik dan een interface.


Antwoord 9

Ik bouw een gebouw van 300 verdiepingen

De blauwdruk van het gebouw interface

  • Bijvoorbeeld Servlet(I)

Gebouw gebouwd tot 200 verdiepingen – gedeeltelijk voltooid—abstract

  • Gedeeltelijke implementatie, bijvoorbeeld generiek en HTTP-servlet

Bouwconstructie voltooid-beton

  • Volledige implementatie, bijvoorbeeld eigen servlet

Interface

  • We weten niets over implementatie, alleen vereisten. Wij kunnen
    ga voor een interface.
  • Elke methode is standaard openbaar en abstract
  • Het is een 100% pure abstracte les
  • Als we openbaar verklaren, kunnen we niet privé en beschermd verklaren
  • Als we abstract declareren, kunnen we niet definitief, statisch, gesynchroniseerd, strictfp en native verklaren
  • Elke interface heeft openbare, statische en definitieve
  • Serialisatie en transiënt zijn niet van toepassing, omdat we geen instantie kunnen maken voor in de interface
  • Niet-vluchtig omdat het definitief is
  • Elke variabele is statisch
  • Als we een variabele binnen een interface declareren, moeten we variabelen initialiseren tijdens het declareren
  • Instance en statische blokkering niet toegestaan

Abstract

  • Gedeeltelijke implementatie
  • Het heeft een abstracte methode. Een toevoeging, het gebruikt beton
  • Geen beperking voor modifiers van abstracte klassenmethoden
  • Geen beperking voor modifiers van abstracte klassevariabelen
  • We kunnen geen andere modifiers declareren behalve abstract
  • Geen beperking om variabelen te initialiseren

Genomen van de DurgaJobs-website


Antwoord 10

Laten we opnieuw aan deze vraag werken:

Het eerste dat u moet weten, is dat 1/1 en 1*1 hetzelfde opleveren, maar dat betekent niet dat vermenigvuldigen en delen hetzelfde is. Het is duidelijk dat ze een goede relatie hebben, maar let wel, jullie zijn allebei anders.

Ik zal de belangrijkste verschillen aangeven, en de rest is al uitgelegd:

Abstracte klassen zijn handig voor het modelleren van een klassenhiërarchie. Op het eerste gezicht van elke vereiste, zijn we gedeeltelijk duidelijk over wat precies moet worden gebouwd, maar we weten wat te bouwen. En dus zijn uw abstracte klassen uw basisklassen.

Interfaces zijn handig om andere hiërarchieën of klassen te laten weten wat ik kan. En als je zegt dat ik tot iets in staat ben, moet je dat vermogen hebben. Interfaces markeren het als verplicht voor een klas om dezelfde functionaliteiten te implementeren.


Antwoord 11

Het is eigenlijk vrij eenvoudig.

Je kunt een interface zien als een klasse die alleen abstracte methoden mag hebben en niets anders.

Dus een interface kan alleen “declareren” en niet het gedrag definiëren dat je wilt dat de klas heeft.

Met een abstracte klasse kunt u zowel het gedrag declareren (met behulp van abstracte methoden) als definiëren (met behulp van volledige methode-implementaties) het gedrag dat u wilt dat de klasse heeft.

En met een gewone klas kun je alleen het gedrag/de acties die je wilt dat de klas heeft, definiëren, niet declareren.

Nog een laatste ding,

In Java kunt u meerdere interfaces implementeren, maar u kunt er slechts één uitbreiden (Abstract Class of Class)…

Dit betekent dat de overerving van gedefinieerd gedrag beperkt is tot slechts één per klasse… dwz als je een klasse wilt die gedrag van klassen A, B&C omvat, moet je het volgende doen: Klasse A breidt B, Klasse uit C breidt A uit .. het is een beetje een omweg om meerdere overerving te hebben…

Interfaces daarentegen zou je gewoon kunnen doen: interface C implementeert A, B

Dus in feite ondersteunt Java meervoudige overerving alleen in “verklaard gedrag”, dwz interfaces, en alleen enkele overerving met gedefinieerd gedrag.. tenzij je de omweg doet die ik heb beschreven…

Hopelijk is dat logisch.


Antwoord 12

De vergelijking van interface versus abstracte klasse is verkeerd. Er zouden in plaats daarvan twee andere vergelijkingen moeten zijn: 1) interface versus klasse en 2) abstract versus laatste klasse.

Interface versus klasse

Interface is een contract tussen twee objecten. Bijvoorbeeld, ik ben een postbode en jij bent een pakket om te bezorgen. Ik verwacht dat je je afleveradres weet. Als iemand mij een Pakket geeft, moet het het afleveradres weten:

interface Package {
  String address();
}

Klasse is een groep objecten die aan het contract voldoen. Ik ben bijvoorbeeld een doos van de groep “Box” en ik gehoorzaam aan het contract dat vereist is door de postbode. Tegelijkertijd gehoorzaam ik andere contracten:

class Box implements Package, Property {
  @Override
  String address() {
    return "5th Street, New York, NY";
  }
  @Override
  Human owner() {
    // this method is part of another contract
  }
}

Abstract vs Finale

Abstracte klasse is een groep onvolledige objecten. Ze kunnen niet worden gebruikt, omdat ze een aantal onderdelen missen. Ik ben bijvoorbeeld een abstracte GPS-bewuste doos – ik weet hoe ik mijn positie op de kaart moet controleren:

abstract class GpsBox implements Package {
  @Override
  public abstract String address();
  protected Coordinates whereAmI() {
    // connect to GPS and return my current position
  }
}

Deze klasse kan, indien geërfd/uitgebreid door een andere klasse, zeer nuttig zijn. Maar op zichzelf – het is nutteloos, omdat het geen objecten kan hebben. Abstracte lessen kunnen bouwelementen zijn van de laatste lessen.

Laatste klasse is een groep van complete objecten, die kunnen worden gebruikt, maar niet kunnen worden gewijzigd. Ze weten precies hoe ze moeten werken en wat ze moeten doen. Ik ben bijvoorbeeld een Box die altijd naar het adres gaat dat is opgegeven tijdens de constructie:

final class DirectBox implements Package {
  private final String to;
  public DirectBox(String addr) {
    this.to = addr;
  }
  @Override
  public String address() {
    return this.to;
  }
}

In de meeste talen, zoals Java of C++, is het mogelijk om slechts een klasse te hebben, niet abstract of definitief. Zo’n klasse kan worden geërfd en kan worden geïnstantieerd. Ik denk echter niet dat dit strikt in overeenstemming is met het objectgeoriënteerde paradigma.

Nogmaals, het vergelijken van interfaces met abstracte klassen is niet correct.


Antwoord 13

Als je een aantal algemene methoden hebt die door meerdere klassen kunnen worden gebruikt, kies dan voor abstracte klassen.
Als je wilt dat de lessen een duidelijke blauwdruk volgen, ga dan voor interfaces.

De volgende voorbeelden tonen dit aan.

Abstracte klasse in Java:

abstract class Animals
{
    // They all love to eat. So let's implement them for everybody
    void eat()
    {
        System.out.println("Eating...");
    }
    // The make different sounds. They will provide their own implementation.
    abstract void sound();
}
class Dog extends Animals
{
    void sound()
    {
        System.out.println("Woof Woof");
    }
}
class Cat extends Animals
{
    void sound()
    {
        System.out.println("Meoww");
    }
}

Hier volgt een implementatie van de interface in Java:

interface Shape
{
    void display();
    double area();
}
class Rectangle implements Shape 
{
    int length, width;
    Rectangle(int length, int width)
    {
        this.length = length;
        this.width = width;
    }
    @Override
    public void display() 
    {
        System.out.println("****\n* *\n* *\n****"); 
    }
    @Override
    public double area() 
    {
        return (double)(length*width);
    }
} 
class Circle implements Shape 
{
    double pi = 3.14;
    int radius;
    Circle(int radius)
    {
        this.radius = radius;
    }
    @Override
    public void display() 
    {
        System.out.println("O"); // :P
    }
    @Override
    public double area() 
    { 
        return (double)((pi*radius*radius)/2);
    }
}

Enkele belangrijke kernpunten in een notendop:

  1. De variabelen die in de Java-interface zijn gedeclareerd, zijn standaard definitief. Abstracte klassen kunnen niet-finale variabelen hebben.

  2. De variabelen die in de Java-interface zijn gedeclareerd, zijn standaard statisch. Abstracte klassen kunnen niet-statische variabelen hebben.

  3. Leden van een Java-interface zijn standaard openbaar. Een Java-abstracte klasse kan de gebruikelijke smaken van klasseleden hebben, zoals privé, beschermd, enz.


Antwoord 14

In het kort zijn de verschillen de volgende:

Syntactische verschillen tussen Interface en Abstract Class:

  1. Methoden en leden van een abstracte klasse kunnen elke zichtbaarheid hebben. Alle methoden van een interface moeten openbaar zijn. //Geldt niet meer uit Java 9
  2. Een concrete onderliggende klasse van een Abstracte klasse moet alle abstracte methoden definiëren. Een Abstracte onderliggende klasse kan abstracte methoden hebben. Een interface die een andere interface uitbreidt, hoeft geen standaardimplementatie te bieden voor methoden die zijn overgenomen van de bovenliggende interface.
  3. Een onderliggende klas kan slechts één klas verlengen. Een interface kan meerdere interfaces uitbreiden. Een klasse kan meerdere interfaces implementeren.
  4. Een onderliggende klasse kan abstracte methoden definiëren met dezelfde of minder beperkende zichtbaarheid, terwijl een klasse die een interface implementeert, alle interfacemethoden als openbaar moet definiëren.
  5. Abstracte klassen kunnen constructors hebben, maar geen interfaces.
  6. Interfaces van Java 9 hebben statische privémethoden.

Nu in interfaces:

public static – ondersteund
public abstract – ondersteund
public default – ondersteund
private static – ondersteund
private abstract – compileerfout
private default – compileerfout
private – ondersteund


Antwoord 15

Het enige verschil is dat de een kan deelnemen aan meervoudige overerving en de ander niet.

De definitie van een interface is in de loop van de tijd veranderd. Denkt u dat een interface alleen methodeverklaringen heeft en alleen contracten zijn? Hoe zit het met statische eindvariabelen en hoe zit het met standaarddefinities na Java 8?

Interfaces werden geïntroduceerd in Java vanwege het diamantprobleem met meervoudige overerving en dat is wat ze eigenlijk van plan zijn te doen.

Interfaces zijn de constructies die zijn gemaakt om het probleem van meervoudige overerving op te lossen en kunnen abstracte methoden, standaarddefinities en statische eindvariabelen hebben.

Zie Waarom staat Java statische eindvariabelen in interfaces toe als ze alleen bedoeld zijn als contracten?.


Antwoord 16

Interface: afslaan (linksaf, rechtsaf.)

Abstracte klasse: wiel.

Klasse: stuurwiel, afgeleid van wiel, onthult Interface Turn

De ene is voor het categoriseren van gedrag dat kan worden aangeboden voor een breed scala aan dingen, de andere is voor het modelleren van een ontologie van dingen.


Antwoord 17

Veel junior ontwikkelaars maken de fout om interfaces, abstracte en concrete klassen te zien als kleine variaties van hetzelfde, en kiezen er een puur op technische gronden voor: Heb ik meervoudige overerving nodig? Heb ik een plaats nodig om gemeenschappelijke methoden te plaatsen? Moet ik me met iets anders bezighouden dan alleen een concrete les? Dit is verkeerd, en in deze vragen zit het grootste probleem verborgen: “Ik”. Wanneer je zelf code schrijft, denk je zelden aan andere huidige of toekomstige ontwikkelaars die aan of met je code werken.

Interfaces en abstracte klassen, hoewel technisch gezien vergelijkbaar, hebben totaal verschillende betekenissen en doelen.

Samenvatting

  1. Een interface definieert een contract waaraan een implementatie voor u zal voldoen.

  2. Een abstracte klasse biedt een standaardgedrag dat uw implementatie opnieuw kan gebruiken.

Alternatieve samenvatting

  1. Een interface is voor het definiëren van openbare API’s
  2. Een abstracte klasse is voor intern gebruik en voor het definiëren van SPI’s

Over het belang van het verbergen van implementatiedetails

Een concrete klas doet het eigenlijke werk, op een heel specifieke manier. Een ArrayList gebruikt bijvoorbeeld een aaneengesloten geheugengebied om een ​​lijst met objecten op een compacte manier op te slaan die snelle willekeurige toegang, iteratie en in-place wijzigingen biedt, maar is verschrikkelijk in invoegingen, verwijderingen, en soms zelfs toevoegingen; ondertussen gebruikt een LinkedList dubbelgekoppelde knooppunten om een ​​lijst met objecten op te slaan, die in plaats daarvan snelle iteratie, in-place wijzigingen en invoeging/verwijdering/toevoeging biedt, maar verschrikkelijk is bij willekeurige toegang. Deze twee soorten lijsten zijn geoptimaliseerd voor verschillende gebruiksscenario’s en het maakt veel uit hoe u ze gaat gebruiken. Wanneer u prestaties probeert te persen uit een lijst waar u veel mee te maken heeft, en wanneer u het type lijst aan u zelf kiest, moet u zorgvuldig kiezen welke u wilt instantiëren.

Aan de andere kant interesseert het gebruikers van een lijst op hoog niveau niet echt hoe deze wordt geïmplementeerd, en ze zouden van deze details moeten worden afgeschermd. Laten we ons voorstellen dat Java de List-interface niet openbaarde, maar alleen een concrete List-klasse had, dat is eigenlijk wat LinkedList op dit moment is. Alle Java-ontwikkelaars zouden hun code hebben aangepast aan de implementatiedetails: willekeurige toegang vermijden, een cache toevoegen om de toegang te versnellen, of gewoon ArrayList zelf opnieuw implementeren, hoewel het incompatibel zou zijn met alle andere code die alleen werkt met List. Dat zou verschrikkelijk zijn… Maar stel je nu eens voor dat de Java-meesters zich realiseren dat een gekoppelde lijst verschrikkelijk is voor de meeste daadwerkelijke gebruiksgevallen, en besloten om over te schakelen naar een arraylijst voor hun enige beschikbare List-klasse . Dit zou de prestaties van elk Java-programma ter wereld beïnvloeden, en mensen zouden er niet blij mee zijn. En de belangrijkste boosdoener is dat implementatiedetails beschikbaar waren, en de ontwikkelaars gingen ervan uit dat die details een permanent contract zijn waarop ze kunnen vertrouwen. Daarom is het belangrijk om implementatiedetails te verbergen en alleen een abstract contract te definiëren. Dit is het doel van een interface: definieer wat voor soort invoer een methode accepteert en wat voor soort uitvoer wordt verwacht, zonder al het lef bloot te leggen dat programmeurs zou verleiden om hun code aan te passen aan de interne details die zouden kunnen veranderen met een toekomstige update .

Een abstracte klasse bevindt zich in het midden tussen interfaces en concrete klassen. Het wordt verondersteld om implementaties te helpen gemeenschappelijke of saaie code te delen. AbstractCollection biedt bijvoorbeeld basisimplementaties voor isEmpty op basis van grootte is 0, contains zoals herhalen en vergelijken, addAll zoals herhaald add, enzovoort. Hierdoor kunnen implementaties zich concentreren op de cruciale onderdelen die ze onderscheiden: hoe gegevens daadwerkelijk kunnen worden opgeslagen en opgehaald.

API’s versus SPI’s

Interfaces zijn gateways met een lage cohesie tussen verschillende delen van code. Ze zorgen ervoor dat bibliotheken kunnen bestaan ​​en evolueren zonder elke bibliotheekgebruiker te breken wanneer er intern iets verandert. Het heet Application Programming Interface, geen Application Programming Classes. Op kleinere schaal stellen ze ook meerdere ontwikkelaars in staat om succesvol samen te werken aan grootschalige projecten, door verschillende modules te scheiden via goed gedocumenteerde interfaces.

Abstracte klassen zijn helpers met een hoge cohesie die gebruikt kunnen worden bij het implementeren van een interface, uitgaande van een bepaald niveau van implementatiedetails. Als alternatief worden abstracte klassen gebruikt voor het definiëren van SPI’s, Service Provider Interfaces.

Het verschil tussen een API en een SPI is subtiel, maar belangrijk: voor een API ligt de focus op wie gebruikt en voor een SPI ligt de focus op wie implementeert het.

Het toevoegen van methoden aan een API is eenvoudig, alle bestaande gebruikers van de API zullen nog steeds compileren. Methoden toevoegen aan een SPI is lastig, aangezien elke dienstverlener (concrete implementatie) de nieuwe methoden zal moeten implementeren. Als interfaces worden gebruikt om een ​​SPI te definiëren, zal een provider een nieuwe versie moeten uitbrengen wanneer het SPI-contract verandert. Als in plaats daarvan abstracte klassen worden gebruikt, kunnen nieuwe methoden worden gedefinieerd in termen van bestaande abstracte methoden, of als lege throw not implemented exception-stubs, waardoor in ieder geval een oudere versie van een service-implementatie nog compileren en uitvoeren.

Een opmerking over Java 8 en standaardmethoden

Hoewel Java 8 standaardmethoden voor interfaces heeft geïntroduceerd, waardoor de grens tussen interfaces en abstracte klassen nog vager wordt, was dit niet zo dat implementaties code kunnen hergebruiken, maar om het gemakkelijker te maken om interfaces te wijzigen die zowel als API en als als een SPI (of worden ten onrechte gebruikt voor het definiëren van SPI’s in plaats van abstracte klassen).

Welke te gebruiken?

  1. Moet het ding openbaar worden gebruikt door andere delen van de code of door andere externe code? Voeg er een interface aan toe om de implementatiedetails te verbergen voor het openbare abstracte contract, wat het algemene gedrag van het ding is.
  2. Is het ding iets dat meerdere implementaties zou moeten hebben met veel gemeenschappelijke code? Maak zowel een interface als een abstracte, onvolledige implementatie.
  3. Zal er ooit maar één implementatie zijn en niemand anders zal het gebruiken? Maak er gewoon een concrete les van.
    1. ‘ooit’ is lang, je zou op veilig kunnen spelen en er nog een interface aan toevoegen.

Een gevolg: andersom wordt vaak verkeerd gedaan: probeer bij het gebruik van een ding altijd de meest generieke klasse/interface te gebruiken die je echt nodig hebt. Met andere woorden, declareer uw variabelen niet als ArrayList theList = new ArrayList(), tenzij u er echt sterk van afhankelijk bent dat het een array-lijst is, en nee een ander type lijst zou het voor je doen. Gebruik in plaats daarvan List theList = new ArrayList, of zelfs Collection theCollection = new ArrayList als het feit dat het een lijst is en niet een ander type verzameling er eigenlijk niet toe doet.


Antwoord 18

Je kunt een duidelijk verschil vinden tussen interface en abstracte klasse.

Interface

  • Interface bevat alleen abstracte methoden.
  • Dwing gebruikers om alle methoden te implementeren wanneer de interface wordt geïmplementeerd.
  • Bevat alleen definitieve en statische variabelen.
  • Declareren met interface-trefwoord.
  • Alle methoden van een interface moeten als openbaar worden gedefinieerd.
  • Een interface kan uitbreiden of een klasse kan meerdere andere implementeren
    interfaces.

Abstracte les

  • Abstracte klasse bevat abstracte en niet-abstracte methoden.

  • Dwingt gebruikers niet om alle methoden te implementeren wanneer ze de . hebben overgenomen
    abstracte klas.

  • Bevat allerlei variabelen, waaronder primitieve en niet-primitieve

  • Verklaar met abstract trefwoord.

  • Methoden en leden van een abstracte klasse kunnen worden gedefinieerd met any
    zichtbaarheid.

  • Een onderliggende klas kan slechts één klas uitbreiden (abstract of concreet).


Antwoord 19

Belangrijkste punten:

  • Abstracte klasse kan eigenschappen, gegevensvelden, methoden hebben (volledig /
    onvolledig) beide.
  • Als methode of Eigenschappen in abstract trefwoord definiëren dat moet worden overschreven in afgeleide klasse. (het werkt als een nauw gekoppelde)
    functionaliteit)
  • Als u abstract trefwoord voor methode of eigenschappen in abstracte klasse definieert, kunt u de hoofdtekst van de methode en de waarde ophalen/instellen voor
    eigenschappen en die moeten worden overschreven in de afgeleide klasse.
  • Abstracte klasse ondersteunt geen meervoudige overerving.
  • Abstracte klasse bevat Constructors.
  • Een abstracte klasse kan toegangsmodificaties bevatten voor de subs, functies, eigenschappen.
  • Alleen volledig lid van abstracte klasse kan statisch zijn.
  • Een interface kan alleen van een andere interface erven en niet van een abstracte klasse, terwijl een abstracte klasse kan erven van een andere abstracte klasse of een andere interface.

Voordeel:

  • Het is een soort contract dat alle subklassen dwingt om dezelfde hiërarchieën of standaarden te hanteren.
  • Als verschillende implementaties van dezelfde soort zijn en gemeenschappelijk gedrag of status gebruiken, is abstracte klasse beter om te gebruiken.
  • Als we een nieuwe methode aan een abstracte klasse toevoegen, hebben we de mogelijkheid om een ​​standaardimplementatie aan te bieden en daarom kan alle bestaande code correct werken.
  • Het maakt een snelle uitvoering mogelijk dan de interface. (interface vereist meer tijd om de eigenlijke methode in de overeenkomstige klassen te vinden.)
  • Het kan worden gebruikt voor strakke en losse koppeling.

vind details hier…
http://pradeepatkari.wordpress. com/2014/11/20/interface-and-abstract-class-in-c-oops/


Antwoord 20

De kortste manier om het samen te vatten is dat een interface is:

  1. Volledig abstract, afgezien van default en static methoden; hoewel het definities heeft (methodehandtekeningen + implementaties) voor default en static methoden, heeft het alleen verklaringen (methodehandtekeningen) voor andere methoden.
  2. Onderworpen aan soepelere regels dan klassen (een klasse kan meerdere interface‘s implementeren, en een interface kan erven van meerdere interface‘s). Alle variabelen zijn impliciet constant, of ze nu gespecificeerd zijn als public static final of niet. Alle leden zijn impliciet public, of ze nu als zodanig zijn gespecificeerd of niet.
  3. Algemeen gebruikt als een garantie dat de implementerende klasse de gespecificeerde functies zal hebben en/of compatibel is met elke andere klasse die dezelfde interface implementeert.

Ondertussen is een abstract klasse:

  1. Overal, van volledig abstract tot volledig geïmplementeerd, met de neiging om een ​​of meer abstract-methoden te hebben. Kan zowel declaraties als definities bevatten, met declaraties gemarkeerd als abstract.
  2. Een volwaardige klasse, en onderhevig aan de regels die gelden voor andere klassen (kan alleen overerven van één klasse), op voorwaarde dat het niet kan worden geïnstantieerd (omdat er geen garantie is dat het volledig wordt geïmplementeerd). Kan niet-constante lidvariabelen hebben. Kan toegangscontrole voor leden implementeren, leden beperken als protected, private of privépakket (niet gespecificeerd).
  3. Over het algemeen gebruikt om ofwel zoveel van de implementatie te bieden als kan worden gedeeld door meerdere subklassen, of om zoveel van de implementatie te bieden als de programmeur kan leveren.

Of, als we het allemaal in één zin willen samenvatten: een interface is wat de implementatieklasse heeft, maar een abstract klasse is wat de subklasse is.


Antwoord 21

Niet echt het antwoord op de oorspronkelijke vraag, maar als je eenmaal het antwoord hebt op het verschil tussen beide, kom je in het dilemma wanneer je ze moet gebruiken:
Wanneer interfaces of abstracte klassen gebruiken ? Wanneer beide gebruiken?

Ik heb beperkte kennis van OOP, maar het zien van interfaces als een equivalent van een bijvoeglijk naamwoord in de grammatica heeft tot nu toe voor mij gewerkt (corrigeer me als deze methode nep is!). Interfacenamen zijn bijvoorbeeld kenmerken of mogelijkheden die u aan een klasse kunt geven, en een klasse kan er veel hebben: ISerializable, ICountable, IList, ICacheable, IHappy, …


Antwoord 22

Overerving wordt voor twee doeleinden gebruikt:

  • Om een ​​object toe te staan ​​gegevensleden van het bovenliggende type en implementaties van methoden als zijn eigen te beschouwen.

  • Om toe te staan ​​dat een verwijzing naar een object van een bepaald type wordt gebruikt door code die een verwijzing naar een supertype-object verwacht.

In talen/frameworks die gegeneraliseerde meervoudige overerving ondersteunen, is het vaak niet nodig om een ​​type te classificeren als een “interface” of een “abstracte klasse”. In populaire talen en frameworks kan een type echter de dataleden of methode-implementaties van een ander type als zijn eigen beschouwen, ook al kan een type een willekeurig aantal andere typen vervangen.

Abstracte klassen kunnen gegevensleden en methode-implementaties hebben, maar kunnen alleen worden overgenomen door klassen die niet van andere klassen erven. Interfaces leggen bijna geen beperkingen op aan de typen die ze implementeren, maar kunnen geen dataleden of methode-implementaties bevatten.

Er zijn momenten waarop het handig is dat typen substitueerbaar zijn voor veel verschillende dingen; er zijn andere momenten waarop het voor objecten nuttig is om gegevensleden van het bovenliggende type en implementaties van methoden als hun eigen te beschouwen. Door een onderscheid te maken tussen interfaces en abstracte klassen, kan elk van deze vaardigheden worden gebruikt in gevallen waar dit het meest relevant is.


Antwoord 23

Ik wil nog een verschil toevoegen dat logisch is.
Je hebt bijvoorbeeld een framework met duizenden regels code. Als u nu een nieuwe functie in de code wilt toevoegen met behulp van een methode enhanceUI(), dan is het beter om die methode in abstracte klasse toe te voegen in plaats van in de interface. Omdat, als u deze methode in een interface toevoegt, u deze in alle geïmplementeerde klassen moet implementeren, maar dat is niet het geval als u de methode in de abstracte klasse toevoegt.


Antwoord 24

Om een ​​eenvoudig maar duidelijk antwoord te geven, helpt het om de context te bepalen: u gebruikt beide wanneer u geen volledige implementaties wilt bieden.

Het belangrijkste verschil is dan dat een interface helemaal geen implementatie heeft (alleen methoden zonder een hoofdtekst), terwijl abstracte klassen ook leden en methoden met een hoofdtekst kunnen hebben, d.w.z. gedeeltelijk kunnen worden geïmplementeerd.


Antwoord 25

Verschillen tussen abstracte klasse en interface ten behoeve van echte implementatie.

Interface: het is een sleutelwoord en wordt gebruikt om de sjabloon of blauwdruk van een object te definiëren en het dwingt alle subklassen om hetzelfde prototype te volgen, wat betreft implementatie, alle subklassen zijn vrij om de functionaliteit te implementeren volgens de vereisten.

Enkele andere gevallen waarin we de interface zouden moeten gebruiken.

Communicatie tussen twee externe objecten (integratie van derden in onze applicatie) gedaan via Interface hier werkt de interface als contract.

Abstracte klasse: Abstract, het is een trefwoord en wanneer we dit trefwoord vóór een klasse gebruiken, wordt het een abstracte klasse. Het wordt voornamelijk gebruikt wanneer we de sjabloon moeten definiëren, evenals een standaard functionaliteit van een object dat wordt gevolgd door alle subklassen en op deze manier verwijdert het de overtollige code en nog een use-case waarin we abstracte klasse kunnen gebruiken, zoals we willen dat geen enkele andere klasse direct een object van de klasse, kunnen alleen afgeleide klassen de functionaliteit gebruiken.

Voorbeeld van abstracte les:

 public abstract class DesireCar
  {
 //It is an abstract method that defines the prototype.
     public abstract void Color();
  // It is a default implementation of a Wheel method as all the desire cars have the same no. of wheels.   
 // and hence no need to define this in all the sub classes in this way it saves the code duplicasy     
  public void Wheel() {          
               Console.WriteLine("Car has four wheel");
                }
           }
    **Here is the sub classes:**
     public class DesireCar1 : DesireCar
        {
            public override void Color()
            {
                Console.WriteLine("This is a red color Desire car");
            }
        }
        public class DesireCar2 : DesireCar
        {
            public override void Color()
            {
                Console.WriteLine("This is a red white Desire car");
            }
        }

Voorbeeld van interface:

  public interface IShape
        {
          // Defines the prototype(template) 
            void Draw();
        }
  // All the sub classes follow the same template but implementation can be different.
    public class Circle : IShape
    {
        public void Draw()
        {
            Console.WriteLine("This is a Circle");
        }
    }
    public class Rectangle : IShape
    {
        public void Draw()
        {
            Console.WriteLine("This is a Rectangle");
        }
    }

Antwoord 26

Ik ben 10 jaar te laat op het feest, maar wil het toch proberen. Een paar dagen geleden een bericht over hetzelfde geschreven. Ik dacht eraan om het hier te plaatsen.

tl;dr; Als je de relatie Is A ziet, gebruik dan overerving/abstracte klasse. als je ziet dat er een relatie is, maak dan lidvariabelen aan. Als u ‘betrouwt op externe provider’ ziet, implementeert (niet erft) een interface.

Interviewvraag: Wat is het verschil tussen een interface en een abstracte klasse? En hoe bepaal je wanneer je wat gebruikt?
Ik krijg meestal een of alle van de onderstaande antwoorden:
Antwoord 1: U kunt geen object van abstracte klasse en interfaces maken.

ZK (Dat zijn mijn initialen): U kunt van geen van beide een object maken. Dit is dus geen verschil. Dit is een overeenkomst tussen een interface en een abstracte klasse. Balie
Vraag: Waarom kun je geen object van een abstracte klasse of interface maken?

Antwoord 2: Abstracte klassen kunnen een functie-body hebben als gedeeltelijke/standaardimplementatie.

ZK: Tegenvraag: Dus als ik het verander in een pure abstracte klasse, markeer dan alle virtuele functies als abstract en bied geen standaardimplementatie voor een virtuele functie. Zou dat abstracte klassen en interfaces hetzelfde maken? En kunnen ze daarna door elkaar worden gebruikt?

Antwoord 3: Interfaces staan ​​multi-overerving toe en abstracte klassen niet.

ZK: Tegenvraag: Erf je echt van een interface? of implementeer je gewoon een interface en erven van een abstracte klasse? Wat is het verschil tussen implementeren en erven?
Deze tegenvragen werpen kandidaten af ​​en doen de meesten hun hoofd krabben of gaan gewoon door naar de volgende vraag. Daarom denk ik dat mensen hulp nodig hebben bij deze basisbouwstenen van objectgeoriënteerd programmeren.
Het antwoord op de oorspronkelijke vraag en alle tegenvragen is te vinden in de Engelse taal en de UML.
Je moet op zijn minst het onderstaande weten om deze twee constructies beter te begrijpen.

Algemeen zelfstandig naamwoord: Een zelfstandig naamwoord is een naam die “gemeenschappelijk” wordt gegeven aan dingen van dezelfde klasse of soort. Voor bijv. fruit, dieren, stad, auto enz.

Eigen naamwoord: Een eigennaam is de naam van een object, plaats of ding. Apple, Cat, New York, Honda Accord enz.

Auto is een algemeen zelfstandig naamwoord. En Honda Accord is een eigennaam, en waarschijnlijk een samengesteld eigennaamwoord, een eigennaam gemaakt met behulp van twee zelfstandige naamwoorden.

Komt naar het UML-gedeelte. U moet bekend zijn met onderstaande relaties:

  • Is A
  • Heeft A
  • Gebruik

Laten we de onderstaande twee zinnen eens bekijken.
– HondaAccord is een auto?
– HondaAccord heeft een auto?

Welke klinkt correct? Gewoon Engels en begrip. HondaAccord en Cars delen een ‘Is A’-relatie. Honda accord heeft geen auto erin. Het is een auto. Honda Accord heeft een muziekspeler.

Als twee entiteiten de ‘Is A’-relatie delen, is dit een betere kandidaat voor overerving. En Heeft een relatie is een betere kandidaat voor het maken van lidvariabelen.
Met dit vastgesteld ziet onze code er als volgt uit:

abstract class Car
{
   string color;
   int speed;
}
class HondaAccord : Car
{
   MusicPlayer musicPlayer;
}

Nu maakt Honda geen muziekspelers. Of het is in ieder geval niet hun hoofdactiviteit.

Dus nemen ze contact op met andere bedrijven en ondertekenen ze een contract. Als je hier stroom ontvangt en het uitgangssignaal op deze twee draden, zal het prima spelen op deze luidsprekers.

Dit maakt Music Player een perfecte kandidaat voor een interface. Het maakt je niet uit wie het ondersteunt, zolang de verbindingen maar goed werken.

Je kunt de MusicPlayer van LG vervangen door Sony of andersom. En het verandert niets aan Honda Accord.

Waarom kun je geen object van abstracte klassen maken?

Omdat je niet een showroom binnen kunt lopen en zeggen: geef me een auto. Je moet een eigennaam opgeven. Welke auto? Waarschijnlijk een Honda Accord. En dat is wanneer een verkoopagent iets voor je kan betekenen.

Waarom kun je geen object van een interface maken?
Want je kunt niet een showroom binnenlopen en zeggen, geef me een contract voor een muziekspeler. Het zal niet helpen. Interfaces zitten tussen consumenten en aanbieders om een ​​overeenkomst te vergemakkelijken. Wat doet u met een kopie van de overeenkomst? Er wordt geen muziek afgespeeld.

Waarom staan ​​interfaces meervoudige overerving toe?

Interfaces worden niet geërfd. Interfaces zijn geïmplementeerd.
De interface is een kandidaat voor interactie met de buitenwereld.
Honda Accord heeft een interface voor het tanken. Het heeft interfaces voor het oppompen van banden. En dezelfde slang die wordt gebruikt om een ​​voetbal op te blazen. De nieuwe code ziet er dus als volgt uit:

abstract class Car
{
    string color;
    int speed;
}
class HondaAccord : Car, IInflateAir, IRefueling
{
    MusicPlayer musicPlayer;
}

En de Engelsen zullen zo lezen: ‘Honda Accord is een auto die het oppompen van banden en tanken ondersteunt’.


Antwoord 27

Een abstracte klasse is een klasse waarvan het object niet kan worden gemaakt of een klasse die niet kan worden geïnstantieerd.
Een abstracte methode maakt een klasse abstract.
Een abstracte klasse moet worden geërfd om de methoden die in de abstracte klasse zijn gedeclareerd, te overschrijven.
Geen beperking op toegangsspecificaties.
Een abstracte klasse kan constructor- en andere concrete (niet-abstarcte methoden) methoden bevatten, maar de interface kan dat niet hebben.

Een interface is een blauwdruk/sjabloon van methoden. (Er wordt bijvoorbeeld een huis op papier gegeven (interfacehuis) en verschillende architecten zullen hun ideeën gebruiken om het te bouwen (de klassen van architecten die de huisinterface implementeren).
Het is een verzameling van abstracte methoden, standaardmethoden, statische methoden, uiteindelijke variabelen en geneste klassen.
Alle leden zijn definitief of openbaar, beschermde en privétoegangsspecificaties zijn niet toegestaan. Het maken van objecten is niet toegestaan.
Er moet een klasse worden gemaakt om de implementatie-interface te gebruiken en ook om de abstracte methode te overschrijven die in de interface is gedeclareerd. Een interface is een goed voorbeeld van losse koppeling (dynamisch polymorfisme/dynamische binding)
Een interface implementeert polymorfisme en abstractie. Het vertelt wat te doen, maar hoe te doen wordt bepaald door de implementerende klasse.
Voor bijv. Er is een autobedrijf en het wil dat sommige functies hetzelfde zijn voor alle auto’s die het produceert, zodat het bedrijf een interface-voertuig zou maken met die functies en verschillende autoklassen (zoals Maruti Suzkhi, Maruti 800) zullen overschrijf deze functies (functies).

Waarom een ​​interface als we al een abstracte klasse hebben?
Java ondersteunt alleen multilevel en hiërarchische overerving, maar met behulp van de interface kunnen we meervoudige overerving implementeren.


Antwoord 28

In praktische termen (JAVA), is het belangrijkste verschil tussen abstracte klasse en interface:
Abstracte klasse kan status behouden.
Behalve het vasthouden van de status kunnen we ook rustbewerkingen met Interface bereiken.


Antwoord 29

In een interface moeten alle methoden slechts definities zijn, niet één moet worden geïmplementeerd.

Maar in een abstracte klasse moet er een abstracte methode zijn met alleen definitie, maar andere methoden kunnen ook in de abstracte klasse zijn met implementatie…


Antwoord 30

We hebben verschillende structurele/syntactische verschillen tussen interface en abstracte klasse. Nog enkele verschillen zijn

[1] Scenariogebaseerd verschil:

Abstracte klassen worden gebruikt in scenario’s waarin we de gebruiker willen beperken om een ​​object van de bovenliggende klasse te maken EN we denken dat er in de toekomst meer abstracte methoden zullen worden toegevoegd.

Interface moet worden gebruikt als we zeker weten dat er geen abstractere methode meer kan worden geleverd. Dan wordt alleen een interface gepubliceerd.

[2] Conceptueel verschil:

“Moeten we in de toekomst meer abstracte methoden bieden”, zo JA, maak er dan een abstracte klasse van en zo nee, maak er dan een Interface van.

(Meest geschikt en geldig tot Java 1.7)

LEAVE A REPLY

Please enter your comment!
Please enter your name here

two × 2 =

Other episodes