[.NET] Welke Inferfaces implementen.

[Verwijderd]

Zoals jullie misschien weten zijn er in .NET de volgende standaard interfaces.

- IComparable
- IEnumerator
- IEnumerable
- IFormattable
- IList
- ICloneable
- IComponent
- IDataErrorInfo

Nu heb ik een class User gemaakt. Je kunt zelf wel ongeveer bedenken welke methoden en attributen deze heeft als ik zeg dat deze een werknemer in een bedrijf moet representeren.

Mijn vraag is hoe kom je tot het besluit om een interfaces te implementeren? Ik zou eerlijk gezegd alle interfaces implementeren zodat de class door allerlei controls gebruikt kan worden, gesorteerd kunnen worden, etc.

Daarnaast heb ik nog een tweede vraag. Hoe zou een interface eruit zien die niet standaard in .NET zit. Welke andere interfaces zijn voor sommige class'es handig die niet in .NET zitten als standaard?

[gorgi_19]

Ik neem aan dat een class niet per definitie alles hoeft te doen?
Zo zal het voor een aantal classes volstrekt onzinnig zijn om sorteerbaar te zijn.

Oftewel: aan de hand van de functionaliteiten van een class bepaal ik welke interfaces er evt. geimplementeerd worden.

[ Voor 30% gewijzigd door gorgi_19 op 02-09-2003 09:38 ]

[Verwijderd]

gorgi_19 schreef op 02 September 2003 @ 09:36:
Ik neem aan dat een class niet per definitie alles hoeft te doen?
Zo zal het voor een aantal classes volstrekt onzinnig zijn om sorteerbaar te zijn.

Ja dat klopt. Als jij een klasse maakt, loop jij dan het lijstje met Interfaces van die in .NET zitten om te kijken welke je allemaal kunt implementeren?

[gorgi_19]

Verwijderd schreef op 02 september 2003 @ 09:38:
[...]


Ja dat klopt. Als jij een klasse maakt, loop jij dan het lijstje met Interfaces van die in .NET zitten om te kijken welke je allemaal kunt implementeren?

Nee, ik kijk wat ik wil dat een class allemaal moet doen en dan ga ik pas kijken welke interfaces ik eventueel implementeer en of er geen betere oplossingen zijn.

Al die interfaces vereisen een aantal methods. En hoe meer (onnodige) zut in m'n class, hoe moeilijker onderhoudbaar / leesbaar die wordt.

[ Voor 15% gewijzigd door gorgi_19 op 02-09-2003 09:42 ]

[Verwijderd]

Interfaces is voor mij nieuw vandaar dat ik er een paar vragen over stel.

Heb jij voorbeelden van jezelf dat je niet de standaard interfaces hebt gebruikt, maar je eigen hebt geschreven?

[whoami]

Verwijderd schreef op 02 September 2003 @ 09:42:
Heb jij voorbeelden van jezelf dat je niet de standaard interfaces hebt gebruikt, maar je eigen hebt geschreven?

Als je een klasse-hierarchy maakt, en je wil dat bepaalde classes aan eenzelfde interface voldoen, dan moet je meestal een eigen interface maken. Je kan het min of meer vergelijken met wanneer je abstract classes maakt.
Zie bv. bepaalde design patterns (abstract factory, strategy, ...)

[gorgi_19]

Verwijderd schreef op 02 september 2003 @ 09:42:
Interfaces is voor mij nieuw vandaar dat ik er een paar vragen over stel.

Heb jij voorbeelden van jezelf dat je niet de standaard interfaces hebt gebruikt, maar je eigen hebt geschreven?

Bij het maken van een custom template column moesten een aantal controls gebind worden. Echter, 2 volstrekt ongerelateerde classes maakten gebruik van deze templatecolumn.

Een cast werd dan ook moeilijk. Om het op te lossen heb ik beide classes een custom interface laten implementeren, waardoor het casten wel mogelijk werd.

[Verwijderd]

hmm ja, inderdaad, als je veel afgeleide klassen hebt, dan is een 'universele' manier om deze aan te spreken wel handig.

Als ik dus een klasse persoon heb. Daar leid ik van af de klassen klant,werknemer.
Dan kijk ik welke methoden door deze alledrie gedeelt wordt. En dan maak ik daar een interface voor?

Maar waarom zorg je niet dat je methoden goed zijn in de hoofdklasse? Ze worden immers toch geerft door die andere?

[ginamri]

Als ik jou was zou ik een IComparable, dan kun je je user class in een Arraylist stoppen en dan sort aanroepen.

IEnumerator,Ienumerable en Ilist horen in het zelfde rijtje.. ditze zijn alleen interesant om lijsten mee te maken.
Met IEnumerator,Ienumerable kun je foreach mee gaan gebruiken.

met de rest ben ik niet zo bekend. Je moet niet zomaar Interfaces gaan impelenteren voor de leuk.. daar heb je niets aan.


deze reacties is tevens van typfouten voorzien

[gorgi_19]

Verwijderd schreef op 02 September 2003 @ 09:51:
Als ik dus een klasse persoon heb. Daar leid ik van af de klassen klant,werknemer.
Dan kijk ik welke methoden door deze alledrie gedeelt wordt. En dan maak ik daar een interface voor?

Waarom maak je daar een interface voor? Een abstract class is dan toch voldoende?

Ginamri schreef op 02 September 2003 @ 09:52:
Als ik jou was zou ik een IComparable, dan kun je je user class in een Arraylist stoppen en dan sort aanroepen.

Wat dan alleen nuttig is als je een class op meer dan 1 verschillende manieren moet sorteren.

[ Voor 31% gewijzigd door gorgi_19 op 02-09-2003 09:54 ]

[whoami]

gorgi_19 schreef op 02 september 2003 @ 09:53:
[...]

Waarom maak je daar een interface voor? Een abstract class is dan toch voldoende?

Program to an interface, not to a class.

Als je enkel een stel functie-definities nodig hebt, is een interface voldoende.
Als je echter ook gemeenschappelijke members of implementatie hebt, dan kan je een abstract class gebruiken.

[whoami]

Verwijderd schreef op 02 September 2003 @ 09:51:
Maar waarom zorg je niet dat je methoden goed zijn in de hoofdklasse? Ze worden immers toch geerft door die andere?

Omdat je in .NET slechts van 1 class kunt inheriten.

[gorgi_19]

whoami schreef op 02 September 2003 @ 10:03:
[...]

Program to an interface, not to a class.

Als je enkel een stel functie-definities nodig hebt, is een interface voldoende.
Als je echter ook gemeenschappelijke members of implementatie hebt, dan kan je een abstract class gebruiken.

Dus jij zegt dat ik moet maken:

Visual Basic .NET:

Public Interface IIncome

      Function GetSalary() as Double

End Interface


Public Class Persoon
    Implements IIncome

    Public Overridable Function GetSalary() as Double Implements IIncome.GetSalary
        
        return 1000
    
    End function

End Class

Public Class Werknemer
    Inherits Persoon
  
    Public Overrides Function GetSalary() as Double
    
        return 1500

    End Function

End class

Is het in dit geval wel nodig, omdat je in principe alles al erft van Persoon?
Aangezien hij volgens mij dit voorbeeld geeft (hij noemt zelf de gemeenschappelijke members.)

En als we met quotes gaan smijten

Make things as simple as possible. Not any simpler"

In principe gebruik ik Interfaces alleen als ik de achterliggende class moet kunnen loskoppelen van een interface en hier wijzigingen op aan moet brengen. 'vaststaande' blokken, welke per definitie een eenheid moeten worden, krijgen bij mij iig geen Interface.

[ Voor 38% gewijzigd door gorgi_19 op 02-09-2003 10:14 ]

[whoami]

gorgi_19 schreef op 02 September 2003 @ 10:06:
[...]

Is het in dit geval wel nodig, omdat je in principe alles al erft van Persoon?
Aangezien hij volgens mij dit voorbeeld geeft (hij noemt zelf de gemeenschappelijke members.)

Nee, je hebt me een beetje verkeerd begrepen denk ik.

Als je overerft van een class (omdat je bv. bepaalde members shared, of als je implementatie moet overerven, dan moet je die abstract class ook niet uit elkaar gaan halen om interfaces te kunnen creeëren.
Die GetSalary hoort bij person, dus laat je die daar dan in die class Person zitten.

[gorgi_19]

whoami schreef op 02 September 2003 @ 10:17:
[...]

Nee, je hebt me een beetje verkeerd begrepen denk ik.

* gorgi_19 heeft er wel vaker last van...

Als je overerft van een class (omdat je bv. bepaalde members shared, of als je implementatie moet overerven, dan moet je die abstract class ook niet uit elkaar gaan halen om interfaces te kunnen creeëren.
Die GetSalary hoort bij person, dus laat je die daar dan in die class Person zitten.

Alleen, haal ik nu die class uit elkaar dan?

Visual Basic .NET:

Dim __income as IIncome = New Werknemer()
Response.Write("Income:" & __income.GetSalary())

hoort 1500 te geven

* gorgi_19 is confused.

[Verwijderd]

Iedereen koffie gehaalt? Kunnen we weer verder ;-)

Waar nu dus verschil van mening is, is juist het gene wat wil weten.

Zijn er geen regels over de implementatie van interfaces?

[farlane]

whoami schreef op 02 September 2003 @ 10:03:
Program to an interface, not to a class.

Zelf ken ik die als
Program to an interface, not an implementation

Maw, ga uit van een interface ( een class heeft dus ook een interface ) en niet van een bepaalde implementatie van een object.

[whoami]

Als GetSalary functioneel bij Person hoort, waarom zou je het dan lostrekken van de class Person en in een aparte interface stoppen?

[gorgi_19]

whoami schreef op 02 september 2003 @ 10:49:
Als GetSalary functioneel bij Person hoort, waarom zou je het dan lostrekken van de class Person en in een aparte interface stoppen?

Dat doe je ook niet. (althans, in mijn voorbeeld niet)

[Verwijderd]

Hele dag nu met interfaces in de weer geweest ;-)

Heb ik het goed als ik zeg: Ik heb een klasse gemaakt die door andere gebruikt gaat worden dmv overerving. Omdat de persoon die de klasse overerft niet precies weet welke code ik in mijn klasse heb staan, maak ik een interface. Aan de hand van de interface krijgt hij te zien welke methodes hij moet 'overriden'. De programmeur moet dan zelf een inhoud geven aan de methodes die aan hem gepresenteerd worden door de interface.

[gorgi_19]

Verwijderd schreef op 02 september 2003 @ 17:13:
Hele dag nu met interfaces in de weer geweest ;-)

Heb ik het goed als ik zeg: Ik heb een klasse gemaakt die door andere gebruikt gaat worden dmv overerving. Omdat de persoon die de klasse overerft niet precies weet welke code ik in mijn klasse heb staan, maak ik een interface. Aan de hand van de interface krijgt hij te zien welke methodes hij moet 'overriden'. De programmeur moet dan zelf een inhoud geven aan de methodes die aan hem gepresenteerd worden door de interface.

Ik heb zo een vaag vermoeden dat je nog niet het verschil weet tussen abstract class en een interface.

[Verwijderd]

gorgi_19 schreef op 02 september 2003 @ 17:26:
[...]

Ik heb zo een vaag vermoeden dat je nog niet het verschil weet tussen abstract class en een interface.

waar zit ik fout?

[gorgi_19]

Visual Basic .NET:

Public MustInherit Class BaseEmployee

    Public Sub New()

        ' Verzin maar een leuke constructor

    End sub

    Public MustOverride Function GetSalary() as Double
    Public MustOverride Function GetVacationDays() as Double

    Public Function GetCurrentVacationDays(NumberOfDaysTaken as Double) as Double
        
        Return GetVacationDays() - NumberOfDaysTaken
 
    End Function

End class

Dit doet wat jij beschrijft, maar is geen Interface.

[ Voor 21% gewijzigd door gorgi_19 op 02-09-2003 18:34 ]

[Verwijderd]

Ik beschrijf

Visual Basic .NET:

public class employee
implements person
....

[gorgi_19]

Verwijderd schreef op 02 September 2003 @ 19:08:
Ik beschrijf

Visual Basic .NET:

public class employee
implements person
....

't is een andere methode om op deze manier met Interfaces te werken, maar nog een tip: houdt op z'n minst enige naming conventions aan, anders raak je binnen no-time de volledige draad kwijt.

Imho heb je in de door jouw geschetste situatie geen Interface nodig.

[ Voor 14% gewijzigd door gorgi_19 op 02-09-2003 19:12 ]

[Verwijderd]

Is het voordeel van een abstracte class niet dat je er al code in de methodes kunt plaatsen en wanneer deze niet worden override, de methodes van de base classe worden opgeroepen?
Bij interfaces ben je verplicht ze te implementeren!

[whoami]

Verwijderd schreef op 02 September 2003 @ 19:42:
Is het voordeel van een abstracte class niet dat je er al code in de methodes kunt plaatsen en wanneer deze niet worden override, de methodes van de base classe worden opgeroepen?
Bij interfaces ben je verplicht ze te implementeren!

Een abstracte class heeft minstens 1 pure virtuele (abstracte) member functie nodig.
Het voordeel van abstracte classes , is dat je functionaliteit die je in alle afgeleide classes moet 'delen' slechts 1x hoeft te implementeren.