[C#]Interface en static properties

[Haan]

Ik zit met het volgende:

-Ik heb een interface gedefinieerd met een aantal methoden en properties:

C#:

public interface IProcessor
    {
        int UpdatedRecords { get; set; }
        int FailedRecords { get; set; }
        int CreatedRecords { get; set; }

        void UpdateRecord(BusinessEntity entity);
        Guid CreateRecord(BusinessEntity entity);
        BusinessEntity CheckRecord(string entity, string keyfield, string keyvalue);
    }

-Ik heb een class "Processor" die deze interface implementeert.

Het probleem is alleen dat ik de properties static wil hebben, zodat ik het aantal records dat is verwerkt op kan vragen. Dat gaat nu niet werken omdat ik daarvoor een instantie van de Processor class moet aanmaken, en dan staan die properties natuurlijk op 0.. (het opvragen gebeurt in een andere class dan waar de Processor wordt gebruikt)

Er zijn natuurlijk wel een aantal oplossingen, maar die zijn allemaal niet mooi, of gewoon ranzig:
-properties niet in de interface definiëren (dat ga ik doen als er geen andere mogelijkheid is)
-aparte static properties in de Processor maken die synchroon lopen met de andere properties..
-zelfde als boven, maar dan de static properties in de class zetten die de Processor gebruikt..

Maar ik hoop dus dat er een manier is waarop ik de properties uit de interface static kan krijgen

[Flard]

Het eerste wat je je denk ik af moet vragen is: als je ze static maakt, hoe ga je ze dan benaderen?
Het is namelijk ook niet mogelijk om die static velden te benaderen via de interface.

Ook vraag ik me af hoe 'static' ze moeten zijn. Als je zometeen twee Processors hebt (dus twee klassen die IProcessor implementeren), FooProcessor en BarProcessor, wat verwacht je dan dan bijv. UpdatedRecords terug geeft: het totaalaantal van dat specifieke type (bijv. alle FooProcessor-instanties) of het totaalaantal van álle processors.

Ik kan me voorstellen dat je het totaalaantal van alle processors wil hebben, in dat geval zou ik het bijhouden in de klasse die de Processors instantieert en/of gebruikt.

[mOrPhie]

Wil jij niet gewoon abstract classes gebruiken ipv interfaces? Dan kun je static properties in de moederimplementatie verwerken.

http://www.google.nl/sear...&btnG=Google+zoeken&meta=
http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx

[ Voor 13% gewijzigd door mOrPhie op 03-12-2008 10:54 ]

[whoami]

Met Flard ...
Waarom wil je deze static ?
Wat als je meerdere processors hebt ?

[Haan]

Het was misschien wat onduidelijk, maar de properties moeten niet static gedefinieerd zijn in de interface, maar de properties in de class die de interface implementeert moeten static zijn.

Ik kan dan bijvoorbeeld gewoon BarProcessor.UpdatedRecords opvragen of FooProcessor.UpdatedRecords etc.

Een abstract class met de methodes abstract en static properties zou opzich wel kunnen, maar dan kan ik niet meer van een andere class erven.

[Flard]

Stel je hebt twee FooProcessors, dan wil je dus het totaal van alle FooProcessors hebben? Zo ja: dan is static een goede optie. Ik weet ook niet in hoeverre die dan abstract moet zijn. In je interface heb je dan ook niet meer die property-definities staan.

In dat geval blijf je denk ik bij het benaderen van die properties. Ik kan me voorstellen dat je ergens een array van IProcessor hebt. Je begrijpt dat je dan niet foreach IProcessor het aantal UpdatedRecords kunt opvragen, met name omdat ze static zijn, maar het is vooral zinloos omdat het static is, en dus al een totaal is (of in ieder geval gelijk voor alle instanties van hetzelfde Type).

Ik persoonlijk, zonder kennis van je specifieke domein, zou eigenlijk gewoon die properties als interfaceproperties definiëren, en dan eventueel een Factory/Repository eroverheen gooien, die de lijst van IProcessor beheert, en dan bijvoorbeeld ook een UpdatedRecords heeft, die de som teruggeeft van de UpdatedRecords van alle instanties in zijn eigen lijst.

[Niemand_Anders]

Haan schreef op woensdag 03 december 2008 @ 11:31:
Het was misschien wat onduidelijk, maar de properties moeten niet static gedefinieerd zijn in de interface, maar de properties in de class die de interface implementeert moeten static zijn.

Ik kan dan bijvoorbeeld gewoon BarProcessor.UpdatedRecords opvragen of FooProcessor.UpdatedRecords etc.

Euh, maar dat is toch gewoon het idee achter een interface? Dat al je implementaties dezelfde properties en methodes hebben.

Een abstract class met de methodes abstract en static properties zou opzich wel kunnen, maar dan kan ik niet meer van een andere class erven.

Een statische property is geen onderdeel van een instance. Je zou hier omheen kunnen werken door een public property in je base class op te nemen welke gewoon de waarde van BaseProcessor.UpdatedRecords terug geeft.

C#:

public abstract class BaseProcessor
{
  private static int updatedRecords;
  public int UpdatedRecords
  {
     get { return BaseProcessor.updatedRecords; }
     set { BaseProcessor.updatedRecords = value; }
  }
}

In bovenstaand voorbeeld heb ik geen rekening gehouden met concurrency (FooProcessor en BarProcessor zullen in dit voorbeeld elkaars waarden overschrijven). Als je vervolgens je processor implementaties laat erven van BaseProcessor, dan voldoet deze aan de interface, terwijl deze toch een statische werking heeft.

[Haan]

Als je vervolgens je processor implementaties laat erven van BaseProcessor, dan voldoet deze aan de interface, terwijl deze toch een statische werking heeft.

Dat is precies hoe ik het net heb gedaan

Alleen dan zit ik inderdaad wel met het concurrency probleem, ik heb alweer gezien dat overriden van static properties ook niet kan

[Flard]

Een static property overriden is ook heel onlogisch, want je kunt namelijk niet meer bepalen welke 'instantie' van de override je wil benaderen.

Stel je BaseProcessor.UpdatedRecords en FooProcessor.UpdatedRecords (en FooProcessor inherit van BaseProcessor). Hoe had je dan gedacht BaseProcessor.UpdatedRecords op te halen? En hoe FooProcessor.UpdatedRecords.

Verder insinueer je met abstracte klassen een generiek model op te zetten, dus allemaal IProcessors die voldoen aan jouw interface. In een lijst van IProcessors weet je dan dus (in principe) ook niet van welk type hij is, en zou je dus ook niet bij de 'typed' static kunnen komen (dus FooProcessor.UpdatedRecords is dan toch 'ontoegankelijk').

[exyll]

code:

interface IFoo
{
   void Bar();
}


class A : IFoo
{
  public static readonly IFoo = new A();
}

class B : IFoo
{
  public static readonly IFoo = new B();
}

Hiermee kun je dus doen:

code:

A.Foo.Bar();
B.Foo.Bar();

of...

code:

class Wrapper
{
    public static readonly IFoo A = new A();
    public static readonly IFoo B = new B();
}

Wrapper.A.Bar();
Wrapper.B.Bar();

Maar ik zou als ik jou was een totaal andere oplossing zoeken. Static stuff gaat niet goed/makkelijk samen met threading/locking/database connections.

[ Voor 2% gewijzigd door whoami op 03-12-2008 15:26 ]

[exyll]

editten kan ook, evenals code-tags gebruiken.

[ Voor 94% gewijzigd door whoami op 03-12-2008 15:26 ]

[whoami]

Haan schreef op woensdag 03 december 2008 @ 12:03:
[...]

Dat is precies hoe ik het net heb gedaan

Alleen dan zit ik inderdaad wel met het concurrency probleem, ik heb alweer gezien dat overriden van static properties ook niet kan

Misschien moet je eens:
- zeggen waarom je persé die properties static wilt hebben ?
- eens eea lezen over wat 'static' precies inhoudt.