När ska jag använda abstrakta klasser och gränssnitt (Interface)? - Java

Abstrakt klass: Player

Instanser:

NPC:Player

Human:Player

Enemy:Player

I den abstrakta klassen stoppar du metoder och logik som är gemensam för alla andra typer - så att du bara behöver skriva koda en gång.(jag är C# mupp inte java, men det är samma mönster)

// LZ

Du hade kunnat ha en abstrakt basklass döpt "unit", där du definierar fält för position, textur och andra gemensamma egenskaper. Eftersom denna är abstrakt så kan du inte instansiera den och det är precis så vi vill ha det, däremot de ärvande klasserna player, enemy och npc är vanliga klasser och kan därför instansieras, eftersom vi vill kunna skapa objekt av dessa typer.
Tack vare arvet från "unit" så kan du också stoppa alla i en lista eller array av typen "unit". I stället för att behöva ha en separat lista för varje klasstyp.

Kortfattat: En abstrakt klass är precis som en vanlig klass, med undantaget att den inte kan/får instansieras. Den agerar således bara som en "mall" för sina ärvande klasser.

Såhär ser jag det:

Interface:
Detta är extremt abstrakt och definerar ingen implementation

Abstract class:
Lite abstrakt då den kan deklarera metoder både med och utan implementation.

Om man ska förenkla det hela så är syftet att du kan definera hur något ska se ut utan att bstämma hur det faktiskt funkar. Detta gör att du kan ha unika implementationer så länge input och output är detsamma.
Ett bra exempel på interface är Listor. Jag antar att du oftast gör såhär:

ArrayList myList = new ArrayList();

Nu har du en ArrayList instans som fungerar som väntat, du kan kalla på dess metoder. Problemet är nu att om du vid ett senare tillfälle vill byta datatyp t en t ex Hashmap så måste du ändra överallt. (Hint: INTE BRA!) Om du istället hade gjort såhär:

List myList = new ArrayList();

Så kan du enbart använda de metoder som finns i List interfacet. Så nu kan du inte använda ArrayList metoderna längre utan enbart de som finns i List. Detta kan vara till en nackdel om det finns en speciell metod i ArrayList du vill använda. Men däremot kan du nu enkelt byta ut datatypen till vad som helst som implementerar List. Detta eftersom programmet vet hur en List ska se ut. En bra regel är att försöka använda så generella interface du kan då det blir enklare i längden.

Observera att dessa koncept kan skilja sig mellan språk och även inom olika versioner av språket. Nu minna jag inte exakt men de har ändrat en del i interfaces i de senare java versionerna.

Här finns lite mer: https://stackoverflow.com/questions/761194/interface-vs-abstr...

Bra analogi:
For eg. A Car and a Truck share a lot of core properties and behaviour of an Automobile abstract class, but they also share some peripheral behaviour like Generate exhaust which even non automobile classes like Drillers or PowerGenerators share and doesn't necessarily defines a Car or a Truck, so Car, Truck, Driller and PowerGenerator can all share the same interface IExhaust.

Ett Interface är ett avtal att klassen som implementerar sagt interface har viss funktionalitet som definieras i interfacet.

Låt säga att du har ett interface kallat "iDrawable" som säger det måste finnas en metod/funktion som heter "Draw()", och att denna metod har returvärdet void och inte har några parametrar.

Då kan du sen loopa över en lista över samtliga objekt som implementerar "iDrawable" och anropa metoden Draw() för varje objekt. Du vet att alla objekt i listan har metoden eftersom interfacet är ett avtal som garanterar det.

Java tillåter inte dig att ärva från multipla klasser. Du kan ärva neråt hur mycket du vill, men enbart från en klass.

Nej.

Kolla denna videon: https://www.youtube.com/watch?v=2aQ9Y7bumts

Nej. Abstrakt klass och Interface är två rätt liknande koncept för två rätt olika användningsområden.

Abstrakt klass använder du när du vill ha en superklass som du inte vill ska kunna instansieras till ett objekt. Den funkar annars precis som en vanlig klass.

Ett Interface är lik en abstrakt klass i det faktum att det inte kan instansieras till ett eget objekt, men till skillnad från en abstrakt klass där de ärvande klasserna automatiskt ärver metoder och fält från superklassen så ser ett Interface till att du (programmeraren) måste implementera vissa metoder i din klass för att få lov att implementera Interfacet. Det är således ett "kontrakt" att klassen uppfyller kraven satta i Interfacet.

I en abstrakt klass kan du koda logik i dina metoder, som de ärvda klasserna kan antingen använda eller ersätta med egen logik - I ett Interface definierar du bara stommen av dina metoder, dvs. namn, returvärdestyp och parametertyper, utan någon som helst logik kådad i interfacet.

//Creating interface that has 4 methods  
interface A{  
void a();//bydefault, public and abstract  
void b();  
void c();  
void d();  
}  
  
//Creating abstract class that provides the implementation of one method of A interface  
abstract class B implements A{  
public void c(){System.out.println("I am C");}  
}  
  
//Creating subclass of abstract class, now we need to provide the implementation of rest of the methods  
class M extends B{  
public void a(){System.out.println("I am a");}  
public void b(){System.out.println("I am b");}  
public void d(){System.out.println("I am d");}  
}  
  
//Creating a test class that calls the methods of A interface  
class Test5{  
public static void main(String args[]){  
A a=new M();  
a.a();  
a.b();  
a.c();  
a.d();  
}}

Syftet med Interface i denna övningen är att det "tvingar" dig att implementera a() b() c() d(), och eftersom du bara implementerar c() i superklassen så måste resten implementeras i subklassen. Och eftersom superklassen B är abstrakt så kan man bara initiera subklassen M

C# exempel, torde vara identiskt med Java.

using System;

namespace sweExample
{
    class Program
    {
        static void Main(string[] args)
        {
            IInterface myInterface = new CommonClass1();
            myInterface.Method0();
            myInterface.Method1();
            myInterface.Method2();

            AbstractClass myAbstractClass = new CommonClass2();
            myAbstractClass.Method0();
            myAbstractClass.Method1();
            myAbstractClass.Method2();

            Console.ReadKey();
        }

        public interface IInterface
        {
            void Method0();
            void Method1();
            void Method2();
        }


        public abstract class AbstractClass
        {
            public void Method0()
            {
                Console.WriteLine("Hello abstract world 0");
            }
            public abstract void Method1();
            public abstract void Method2();
        }

        public class CommonClass1 : IInterface
        {
            public void Method0()
            {
                Console.WriteLine("Hello Implemented interface world 0");
            }

            public void Method1()
            {
                Console.WriteLine("Hello Implemented interface world 1");
            }

            public void Method2()
            {
                Console.WriteLine("Hello Implemented interface world 2");
            }
        }

        public class CommonClass2 : AbstractClass
        {

            public override void Method1()
            {
                Console.WriteLine("Hello Implemented abstract world 1");
            }

            public override void Method2()
            {
                Console.WriteLine("Hello Implemented abstract world 2");
            }
        }
    }
}

Detta kommer printa:

Hello Implemented interface world 0
Hello Implemented interface world 1
Hello Implemented interface world 2
Hello abstract world 0
Hello Implemented abstract world 1
Hello Implemented abstract world 2

using System;

namespace sweExample
{
    class Program
    {
        static void Main(string[] args)
        {
            IInterface myInterface = new CommonClass1();
            myInterface.Method0();
            myInterface.Method1();
            myInterface.Method2();

            AbstractClass myAbstractClass = new CommonClass2();
            myAbstractClass.Method0();
            myAbstractClass.Method1();
            myAbstractClass.Method2();

            Console.ReadKey();
        }

        public interface IInterface
        {
            void Method0();
            void Method1();
            void Method2();
        }


        public abstract class AbstractClass
        {
            public void Method0()
            {
                Console.WriteLine("Hello abstract world 0");
            }
            public abstract void Method1();
            public abstract void Method2();
        }

        public class CommonClass1 : IInterface
        {
            public void Method0()
            {
                Console.WriteLine("Hello Implemented interface world 0");
            }

            public void Method1()
            {
                Console.WriteLine("Hello Implemented interface world 1");
            }

            public void Method2()
            {
                Console.WriteLine("Hello Implemented interface world 2");
            }
        }

        public class CommonClass2 : AbstractClass
        {

            public override void Method1()
            {
                Console.WriteLine("Hello Implemented abstract world 1");
            }

            public override void Method2()
            {
                Console.WriteLine("Hello Implemented abstract world 2");
            }
        }
    }
}

Hello Implemented interface world 0
Hello Implemented interface world 1
Hello Implemented interface world 2
Hello abstract world 0
Hello Implemented abstract world 1
Hello Implemented abstract world 2

litet fel här där myInterface.Method0() borde vara myAbstractClass.Method0() osv

AbstractClass myAbstractClass = new CommonClass2();
            myInterface.Method0();
            myInterface.Method1();
            myInterface.Method2();

@heretic16: Du är på rätt väg.

För att en klass ska få lov att implementera ett Interface, så måste klassen åtminstone implementera det som Interfacet säger.
Interfacet säger dock aldrig hur logiken i metoderna ska se ut. Och klassen kan alltid ha ytterligare egenskaper och funktionalitet utöver kraven från Interfacet.

En annan viktig grej är att en klass dessutom kan implementera multipla Interface. Class A Implements Interface1, Interface2, Interface3 etc.

Varvid när det kommer till abstrakta (eller vanliga) klasser så kan en klass bara ärva från en styck annan klass.

Detta är ett rätt luddigt område, det kan ta tid innan polletten trillar ner. Speciellt innan man förstår i vilka situationer man själv kan/bör använda sig av dessa koncept.

Jag läste något för ett antal år sedan som hjälpte mig lite att förstå skillnaderna.
"A class defines who you are, and an interface tells what roles you could play"

Så om Jimmie Åkesson hade fått beskriva så hade han sagt: Klassen innehåller din nedärvda essens, och Interfacet beskriver vad du kan erbjuda arbetsmarknaden

Nja, säg att du har flera olika klasser som principiellt är så pass annorlunda att de inte kan ärva från samma superklass. Men de har fortfarande en eller flera funktioner som är samma.

Till exempel du kan ha en abstrakt klass som heter "fordon", med både "cykel" och "bil" som underklasser. Det blir ju rätt när man säger att en cykel är ett fordon. Men sen vill du stoppa in "människa" under "fordon". En människa är ju inte ett fordon.

Men både människan och diverse fordon kan ju röra på sig. Båda har funktionen accelereration.

Så i stället för att stoppa klassen "människa" som underklass till den abstrakta klassen "fordon" så kan du skapa interfacet "IAccelerate" med metoden "Accelerate()" och implementera det på både den abstrakta klassen "fordon" och den lösa klassen "människa".

Hänger du med hur jag menar?

abstrakt class fordon implements IAccelerate -> class bil & class cykel
class människa implements IAccelerate

Sen kan du klumpa ihop allihopa i en lista av typen IAccelerate, loopa över dem med en for each/for-loop och anropa metoden Accelerate() för samtliga. Detta är iaf. ett av de praktiska användningsområdena med interface.

Interface kommer du se fördelar med när du jobbar i stora gemensamma projekt. Är ett måste då om man jobbar inom samma område och skriver klasser som andra ska använda sig av.

Skickades från m.sweclockers.com

Ok, kör ett exempel i C# då jag bara har Visual Studio på denna burken. Men det fungerar i stort sett likadant i Java.
I C# fungerar "class : class" som javas inherits, och "class : interface" som javas implements.

namespace InterfaceExempel
{
    interface IAccelerate
    {
        int Accelerate();
    }

    interface IDeaccelerate
    {
        int Deaccelerate();
    }

    interface IMovable : IAccelerate, IDeaccelerate { } // Går bra att skapa ett inteface som är en sammansättning av flera mindre interface

    abstract class Vehicle : IMovable
    {
        private int speed = 0;

        public int Accelerate()
        {
            return speed += 1;
        }

        public int Deaccelerate()
        {
            return speed -= 1;
        }
    }

    class Car : Vehicle { }
    class Bicycle : Vehicle { }

    class Human : IMovable
    {
        private int speed = 0;

        public int Accelerate()
        {
            return speed += 1;
        }

        public int Deaccelerate()
        {
            return speed -= 1;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {

            Car car = new Car();
            Bicycle bicycle = new Bicycle();
            Human human = new Human();

            IMovable[] movingObjects = new IMovable[] { car, bicycle, human };

            foreach (IMovable obj in movingObjects)
            {
                obj.Accelerate();
            }

            foreach (IMovable obj in movingObjects)
            {
                obj.Deaccelerate();
            }
        }
    }
}

Som du ser så är Interface ett bra sätt att klumpa ihop klasser (som annars är helt olika varandra) efter en eller flera gemensamma funktioner.
Varvid abstrakta klasser är bra när man behöver klumpa ihop klasser efter gemensamma egenskaper.

Nu är jag ju inte java mupp som sagt, men generellt så är Interface:t det kontrakt som man visar upp utåt - det är en abstraktion från koden. Vilket gör att man kan ha flera versioner av interface mot samma klass. T.ex. Playerv10 som sedan efterföljs av Player11 kontraktet om det är så att funktionerna inte är bakåtkompatibla.

Fast i läget som vi pratar om nu, med player etc så skulle jag se player som bas-klass och de andra klasserna som arv från den klassen - med vinsten att man har gemensam kod på 1 ställe(och gemensamma egenskaper)

// LZ