Abstract eller VIRTUAL

[HDSoftware]

Folkens...

 

Har aldri brukt abstract modifier før så jeg tenkte jeg skulle lese litt om den og som sagt så gjort. Dermed blei jeg litt overrasket for dette ga meg svert lite

 

Hva er fordelen med å lage abstrakte klasser, metoder og properties ?

 

Jeg mener, å arve en klasse gir jo akkurat det samme. Eneste forskjellen er at en abstrakt metode ikke inneholder kode og at abstrakte ting må implementeres i klassen som nedarver, men hvorfor er dette en fordel da?

 

Ved å bruke vanlig VIRTUAL så kan jeg jo faktisk ha grunnleggende kode og det går jo ikke i en abstrakt klasse. Er egentlig en abstrakt klasse bare å se på som en "mal" for nye klasser? I så fall - hva er poenget? Man må jo alikevel kode innholdet på ett eller annet tidspunkt. Og hvis meningen er å bruke abstrakt til å lage et slags felles oppsett på en klasse så kan man jo like gjerne bruke INTERFACE.

 

Hva har jeg egentlig gått glipp av her?

[JAPCU]

Ved å bruke vanlig VIRTUAL så kan jeg jo faktisk ha grunnleggende kode og det går jo ikke i en abstrakt klasse.

Går også an å ha kode som utfører ting i abstrakte klasser, bare ikke i metodene som er deklarert abstrakt.

 

Abstrakte klasser kan også inneholde kode som kaller abstrakte metoder:

 

    
class Program
   {
       static void Main(string[] args)
       {
           DriverJon driverJon = new DriverJon();
           driverJon.driveCar();
       }
   }

   abstract class Driver
   {
       public void driveCar()
       {
           turnKey();
       }

       protected abstract void turnKey();
   }

   class DriverJon : Driver
   {
       protected override void turnKey()
       {
           Console.WriteLine("Click, zzzuh zuh zuh zuh zuh zuh GROOOOOOW. brrrrr");
       }
   }

 

F.eks kan en abstrakt klasse inneholde grunnleggende funksjoner som alle de spesialiserte typene må ha. Hvis de har noen spesielle oppstartsregler eller unntak av noe slag skilles dette ut i en eller flere abstrakte metoder.

 

Fant info her (Java, men gjelder også for C#):

http://www.javaworld.com/javaworld/javaqa/...act.html?page=1

Endret 22. april 2009 av JAPCU

[GeirGrusom]

En bruker vel ofte en blanding av interface og abstrakte klasser, siden disse har to litt forskjellige funksjoner.

 

Interface brukes ofte på subklassene for å sikre at de implementerer viktige funksjoner.

[HDSoftware]

Klarer du være mer spesifik? Kan du gi et eksempel der ABSTRACT må brukes i stedet for en virtuell klasse/metode?

[GeirGrusom]

public abstract class BaseGraphicsObject
{
 protected Rectangle m_bounds;
 public Rectangle Bounds { get { return m_bounds; } set { m_bounds = value; } }
 public abstract void Render(Graphics g);
}
public class Circle : BaseGraphicsObject
{
 public override void Render(Graphics g)
 {
g.DrawEllipse(m_bounds);
 }
}

Endret 24. april 2009 av GeirGrusom

[HDSoftware]

public abstract class BaseGraphicsObject
{
 protected Rectangle m_bounds;
 public Rectangle Bounds { get { return m_bounds; } set { m_bounds = value; } }
 public abstract void Render(Graphics g);
}
public class Circle : BaseGraphicsObject
{
 public override void Render(Graphics g)
 {
g.DrawEllipse(m_bounds);
 }
}

Blir ikke dette det samme som:

public class BaseGraphicsObject
{
 public virtual void Render(Graphics g){}
}
public class Circle : BaseGraphicsObject
{
 public override void Render(Graphics g)
 {
g.DrawEllipse(m_bounds);
 }
}

[steingrim]

I det første tilfellet tvinger du subklassen til å implementere Render(), mens i det andre tilfellet er det valgfritt.

 

Stor forskjell

[BennyXNO]

Et annet problem er at du kan opprette et objekt av typen BaseGraphicsObject, men når det er abstrakt, så forhindrer du at det kan skje.

[HDSoftware]

I det første tilfellet tvinger du subklassen til å implementere Render(), mens i det andre tilfellet er det valgfritt.

 

Stor forskjell

Ahh, skjønner. Så abstrakte klasser etc, blir faktisk ikke tatt med av kompilatoren hvis de ikke er i bruk. Den kjøper jeg...

[GeirGrusom]

Dessuten er det veldig upraktisk om du lager et bibliotek, og det er plutselig lov å instansiere grunnklassen, kan skape problemer.

Abstrakte klasser er en mellomting mellom interfaces og vanlige klasser. De kan ikke instansieres, og alle abstrakte medlemmer må overrides (som interfaces) men de kan ha felt, funksjonskropper, og en annen klasse kan kun arve fra én abstrakt klasse (som vanlige klasser)

 

I C++ finnes det ikke interfaces, men en abstrak klasse som er definert med kun pure virtual functions vil oppføre seg på samme måten (siden C++ støtter multiple inheritance)

[HDSoftware]

ok. Begynner å se helheten... Er ikek vandt til abstrakte klasser i Clarion. Der er det kunn mulig å definere klasser og interfaces. I Clarion er et interface definert kunn med metoder og metodene MÅ implementeres i klassen som implementerer interfacet. Dessuten kan ikke et interface ha egenskaper, altså veldig begrenset i OOP sammenheng.