Avatar billede bdef Novice
01. juni 2011 - 18:24 Der er 13 kommentarer og
1 løsning

Hjælp med at forstå interfaces

Først definere jeg en kunde. Først som interface og siden som class:

interface IKunde
{
  bool OpretOrdre();
}
public class Kunde : IKunde
{
  public bool OpretOrdre()
  {
      return false;
  }
}

Det gik godt. Nu vil jeg oprette kunder. Ligledes først som interface og siden som class, men:

interface IKunder
{
  IKunde FindKunde(string navn);
}
public class Kunder : IKunder
{
  public IKunde FindKunde(string navn)
  {
      return null;
  }
}

Jeg får fejlen:
Inconsistent accessibility: return type 'Model.IKunde' is less accessible than method 'Model.Kunder.FindKunde(string)'

Jeg kan ikke se hvad jeg har gjort forkert.

Og et lille tillægsspørgsmål: Taber jeg muligheden for at lave en konstruktor på kunde, når jeg bruger interfaces?
Avatar billede arne_v Ekspert
01. juni 2011 - 18:27 #1
proev:

public interface IKunde
public interface IKunder
Avatar billede arne_v Ekspert
01. juni 2011 - 18:28 #2
Nej - du kan sagtens lave konstruktor i klasser som implementerer interfaces.

Interfaces et minimums krav til metoder - det er fuldt legalt at have flere metoder inkl. konstruktor.
Avatar billede bdef Novice
01. juni 2011 - 19:30 #3
tak. Det med public, som jeg troede var underforstået, virkede.

Hov. Tror det med constructoren også lykkes. har jeg forstået det rigtigt at constructoren ikke skal defineres på interfacet, men kun på selve klassen?

PS: Smid lige et svar.
Avatar billede arne_v Ekspert
01. juni 2011 - 19:44 #4
Metoderne i et interface er default public, men selve interfacet er ikke.
Avatar billede arne_v Ekspert
01. juni 2011 - 19:44 #5
Man kan ikke definere en constructor i et interface, saa det er kun paa klasserne.
Avatar billede arne_v Ekspert
01. juni 2011 - 19:44 #6
og et svar
Avatar billede bdef Novice
01. juni 2011 - 19:52 #7
Tak for forklaringen. Der er noget som bare er logisk og andet jeg bare acceptere til det bliver logisk for mig :-)
Avatar billede arne_v Ekspert
01. juni 2011 - 20:09 #8
Taenk paa et interface som en kontrakt.

public class Foobar : IFoobar

laeses som:

"Jeg klassen Foobar lover hermed at implementere alle metoder angivet i IFoobar"
Avatar billede johny Nybegynder
02. juni 2011 - 13:56 #9
Og angående det med konstruktøren, hvis det var en del af interfacet, så vil du ikke kunne lave forskellige klasser med samme interface, men med vidt forskellige opsætning, f.eks.

interface IPerson

class PersonInMemory : IPerson
{
  PersonInMemory(){ /*opsætning af en alm. liste*/ }
}


class PersonInDb : IPerson
{
  PersonInDb(string dbConnectionString){ /*opsætning af db*/ }
}

Jeg ved ikke om det var den logik du ledte efter, ellers bare spørg. Al logikken er skam velovervejet, så ingen grund til at stille sig tilfreds med "sådan er det åbenbart". ;)
Avatar billede bdef Novice
02. juni 2011 - 16:56 #10
Godt eksempel. Det giver god mening. Tak for det :-)
Avatar billede janus_007 Nybegynder
02. juni 2011 - 21:39 #11
Eksempler på ligegyldig anvendelse af interfaces :-) imho :)

Det giver ikke den store mening at introducere interfaces for kun at benytte kontraktuelle behov.

Typisk ville jeg nok gøre noget alá:

public interface IQuery<T>
{
  T Find(string searchText);
}

public class Kunde : IQuery<EntityKunde>
{
  EntityKunde Find(string searchText){....}
}
public class Ordre: IQuery<EntityOrdre>
{
  EntityOrdreFind(string searchText){....}
}

Det giver en meget begrænset mening at smide et interface på en entitet bare fordi man kan :) teoretisk og i skolebøger er det skide smart, men i praksis ser det lidt anderledes ud og giver faktisk ofte anledning til mere unødig kompleks kode og spild af tastetryk :)
Avatar billede johny Nybegynder
02. juni 2011 - 23:48 #12
Det kommer helt an på hvad det skal bruges til. For dem der bruger dependency injection frameworks er det et must.
Avatar billede janus_007 Nybegynder
06. juni 2011 - 20:11 #13
Hej johny

Interessant diskussion, vil du forklare hvorfor det kommer an på hvad det skal bruges til? 100% enig med DI, men hvorfor mener du der skal bruges interfaces på data transfer classes (dto) ? sålænge vi ikke krydser nogle fysiske lag, eller på klasser som har specifikke navngivet metoder?

Er det ikke at overgøre det lidt?
Avatar billede johny Nybegynder
07. juni 2011 - 09:13 #14
Jeg går ikke ud fra at der er tale om DTO objekter når det indeholder metoder som "OpretKunde", men at der er tale om en data klasse der indeholder sin egen logik til kontakt med datalaget.

Jeg er helt enig i DTO tilfælde, selvom der kan være interfaces der er nyttige der også i forbindelse med serialisering, men det har dog ikke så meget at gøre med hvad det bliver brugt til her i tråden.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester