Voordeel van polymorfisme

Toen ik begon te zoeken naar de voordelen van polymorfisme, vond ik met dezevraag hier . Maar hier kon ik mijn antwoord niet vinden. Laat me vertellen wat ik wil vinden. Hier heb ik wat lessen:

class CoolingMachines{
    public void startMachine(){
        //No implementationion
    }
    public void stopMachine(){
        //No implementationion
    }
}
class Refrigerator extends CoolingMachines{
    public void startMachine(){
        System.out.println("Refrigerator Starts");
    }
    public void stopMachine(){
        System.out.println("Refrigerator Stop");
    }
    public void trip(){
        System.out.println("Refrigerator Trip");
    }
}
class AirConditioner extends CoolingMachines{
    public void startMachine(){
        System.out.println("AC Starts");
    }
    public void stopMachine(){
        System.out.println("AC Stop");
    }
}
public class PolymorphismDemo {
    CoolingMachines cm = new Refrigerator();
    Refrigerator rf = new Refrigerator();
}

Hier heb ik twee objecten gemaakt in de Demo-klasse en zijn referenties van Refrigerator. Ik heb volledig begrepen dat ik vanuit het rf-object de trip()-methode van Refrigeratorkan aanroepen, maar die methode wordt verborgen voor het cm-object. Nu is mijn vraag waarom zou ik polymorfisme gebruiken of waarom zou ik

CoolingMachines cm = new Refrigerator();

wanneer ik het goed vind

Refrigerator rf = new Refrigerator();

Is de efficiëntie van polymorfe objecten goed of licht in gewicht? Wat is het basisdoel en het verschil tussen beide objecten? Is er een verschil tussen cm.start();en rf.start()?

Antwoord 1, autoriteit 100%

Het is handig als je lijsten afhandelt…
Een kort voorbeeld:

List<CoolingMachines> coolingMachines = ... // a list of CoolingMachines 
for (CoolingMachine current : coolingMachines) {
    current.start();
}

Of wanneer u een methode wilt laten werken met een subklasse van CoolingMachines

Antwoord 2, autoriteit 79%

In gevallen waarin je het echt goed vindt om de concrete klasse te kennen, is er geen voordeel. In veel gevallen wil je echter code kunnen schrijven die alleen de basisklasse of interface kent.

Bekijk bijvoorbeeld Iterablesin Guava– dat zijn veel methoden die (meestal) het maakt niet uit welke implementatie van Iterablewordt gebruikt. Zou je echt al die code apart willen hebben voor elke implementatie?

Waar je kuntcoderen naar een abstracte basisklasse of een interface, sta je jezelf toe om later andere implementaties te gebruiken die dezelfde openbare API delen, maar mogelijk verschillende implementaties hebben. Zelfs als u slechts een enkele productieimplementatie wilt, wilt u wellicht alternatieve implementaties om te testen. (De mate waarin dit van toepassing is, hangt sterk af van de betreffende klasse.)

Antwoord 3, autoriteit 42%

Want als u later AirConditionerin plaats van Refrigeratorwilt gebruiken voor koeling, hoeft u alleen de code te wijzigen CoolingMachines cm = new AirConditioner();

Antwoord 4, autoriteit 23%

De reden waarom je het wilt gebruiken

CoolingMachines cm = new Refrigerator();

is dat je later gemakkelijk een andere CoolingMachineskunt gebruiken. U hoeft slechts die ene regel code te wijzigen en de rest van de code werkt nog steeds (omdat deze alleen methoden van CoolingMachinesgebruikt, wat algemener is dan een specifieke machine, zoals een Refrigerator).

Dus voor een bepaald exemplaar van Refrigeratorwerken de aanroepen cm.start();en rf.start()op dezelfde manier maar cmkan ook een ander CoolingMachines-object zijn. En dat object zou een andere implementatie van start()kunnen hebben.

Antwoord 5, autoriteit 10%

Eerste antwoord:

Gebruik polymorfisme voor overschrijven van methoden en overbelasting van methoden. Andere klassenmethodes die in een andere klasse worden gebruikt, dan twee opties: de eerste methode wordt geërfd, de tweede methode wordt overschreven. Breid hier de interface uit: gebruik ze, of implementatiemethode: logische schrijf ze. Polymorfisme gebruikt voor methode, klasse-overerving.

Tweede antwoord:

Is er een verschil tussen cm.start();en rf.start();?

Ja, beide zijn objecten die totaal verschillend zijn ten opzichte van elkaar. Maak geen interface-objecten omdat Java geen interface-objecten ondersteunt. Eerste object gemaakt voor interface en tweede voor koelkastklasse. Tweede object nu.

Antwoord 6, autoriteit 7%

Het meest algemene antwoord op het algemene deel van uw vraag (waarom zou ik polymorfisme gebruiken?) is dat polymorfisme een aantal kritische objectgeoriënteerde ontwerpprincipes realiseert, bijvoorbeeld:

• hergebruik van code:
  Door een code die gemeenschappelijk is voor al uw ‘koelmachines’ in de koelmachine te plaatsen, hoeft u die code maar één keer te schrijven en eventuele wijzigingen aan die code worden onmiddellijk doorgevoerd.

• abstractie:
  Menselijke hersenen kunnen maar zoveel dingen bijhouden, maar ze zijn goed in categorieën en hiërarchieën. Dit helpt te begrijpen wat er in een groot programma gebeurt.

• inkapseling:
  elke klasse verbergt de details van wat het doet en bouwt gewoon voort op de interface van de basisklasse.

• scheiding van zorgen:
  veel objectgeoriënteerd programmeren gaat over het toewijzen van verantwoordelijkheden. Wie gaat daar verantwoordelijk voor zijn? Gespecialiseerde problemen kunnen in subklassen gaan.

Dus polymorfisme is slechts een deel van het grotere oo-beeld, en de redenen om het te gebruiken zijn soms alleen logisch als je ‘echte’ oo-programmering gaat proberen.

Antwoord 7, autoriteit 5%

Een eenvoudig gebruiksvoorbeeld van polymorfisme is dat u een reeks koelmachines kunt hebben waarbij element 0 een koelkast is en element 1 een airconditioning, enz…

U hoeft geen controles uit te voeren of te controleren met welk object u te maken heeft om trip of start etc. te bellen.

Dit kan een groot voordeel zijn wanneer u invoer van een gebruiker nodig heeft en alle objecten moet herhalen en vergelijkbare functies moet aanroepen

Antwoord 8, autoriteit 3%

Ik zal een gemakkelijk te begrijpen voorbeeld geven. Laten we zeggen dat je een json hebt

{"a":[1,2],"sz":"text", "v":3, "f":1.2}

Laten we nu programmatisch zeggen dat u de naam, het type en de waarde wilt vermelden. In plaats van een switch() voor elk type (array voor a, string voor sz, enz.) kun je gewoon een basistype hebben en een functie aanroepen die zijn werk doet. Het is ook cpu-efficiënter dan het gebruik van een switch met een tiental typen.

Dan zijn er plug-ins, bibliotheken en buitenlandse code met interface-redenen.

Antwoord 9, autoriteit 3%

Uw objecten polymorf gebruiken helpt ook om fabrieken of families van gerelateerde klassen te maken, wat een belangrijk onderdeel is van hoe Factory Ontwerppatroonis geïmplementeerd. Hier is een heel eenvoudig voorbeeld van een polymorfe fabriek:

public CoolingMachine CreateCoolingMachines(string machineType)
{
    if(machineType == "ref")
        return new Refrigerator();
    //other else ifs to return other types of CoolingMachine family
}

gebruik van bovenstaande oproepcode:

CoolingMachine cm = CreateCoolingMachine("AC"); //the cm variable will have a reference to Airconditioner class which is returned by CreateCoolingMachines() method polymorphically

Stel je ook voor dat je een methode hebt zoals hieronder die de concrete klassenparameter Refrigeratorgebruikt:

public void UseObject(Refrigerator refObject)
{
    //Implementation to use Refrigerator object only
}

Als u nu de bovenstaande implementatie van de UseObject()-methode wijzigt om de meest generieke basisklasse-parameter te gebruiken, zou de aanroepende code voordeel hebben om elke parameter polymorf door te geven die vervolgens kan worden gebruikt in de methode UseObject():

public void UseObject(CoolingMachine coolingMachineObject)
{
    //Implementation to use Generic object and all derived objects
}

Bovenstaande code is nu meer uitbreidbaar omdat andere subklassen later aan de familie van . kunnen worden toegevoegd
CoolingMachines en objecten van die nieuwe subklassen zouden ook werken met de bestaande code.