Lave en begrændset klasse?

en klasse som implementerer interface X og Y, X har property A og B, Y har property B og C,
klassen har naturligvis alle tre, properties encapsulater fields

Hvorfor beruger du ikke bare private (eller protected / internal) på dine fields og dine funktioner?

Interfaces er i hvert fald ikke beregnet til at skulle begrænse adgang.

Altså, jeg laver noget remoting og har en User klasse. Klassen indeholder username, status osv for et chat program. Jeg vil gerne have et objekt over hver user hos clienten også, men i User klassen er der ting som clienten ikke må få adgang til, kun server.

Arne:
men man kan jo ikke definere fields i et interface`?

hmm, så har jeg vidst misforstået noget...

Du kan ikke definere fields i et interface, men du kan definere properties !

hmm, hvordan gøres det?

http://msdn2.microsoft.com/en-us/library/64syzecx.aspx

Hvis du skal beskytte et netode eller et felt imod at blive brugt uden for en klasse, så skal du erklære det som:

private - så er det kun klassen semv som bø bruge det.
protected - så er det kun klasser som arver fra klassen som må bruge det.
internal - så er det kun andre klasser der ligger inde i samme assembly som må bruge det.

Du beskytter ingen ting med et interface. Pointen med et interface er nærmest den omvendte: At definere et minimum af metoder og properties som en given klasse viser udad til. Ikke til at skjule metoder.

Hvis at du har data på serveren som klienterne ikke skal have, så er den bedste sikkerhed imidlertid at lade være med at sende dem til klienten.

Normal accessability virker kun hvis de 2 forskellige consumere er i forskellig kategori.

Hvis ikke saa er en koorperativ loesning med 2 forskellige interfaces en praktisk loesning.

Alternativet (hvis vi antager at de 2 consumere er i forskellige assemblies, men det
lyder sandsynligt) er at give dem internal acccess og saa bruge InternalsVisibleToAttribute
til at styre adgangen. Men det synes jeg ikke er en paen loesning.

men hvis jeg har en List<> med mit object, kan jeg så ikke lave en anden klasse der kun har de ting som klienten må se, og så konvertere det til det object?

F.eks:

class User
{
    public string Username;
    Public string Password;
}

class LimitedUser
{
    public string Username;
}

User U = new User();
LimitedUser LU = (LimitedUser)U;

Og derved overfører værdierne?

I det der tilfælde er der intet som forhindre dem i at caste tilbage til User-klassen.

Du kan ikke caste paa den maade.

Men du kan godt returnere dem noget som de kun kender som et interface med de properties
de har lov til at se.

Loesningen er koorperativ i den forstand at consumer kan caste til original typen.

Bemaerk at bruge af accessability kan ogsaa omgaaes ved brug af reflection.

... Hvis altså consumer har _adgang_ til originaltypen.

Jeg forstod på trådstarter, at der var tale om en remoting-løsning. Reelt vil det være muligt at implementere med en soap-formatter i stedet for en binær-formatter. I det tilfælde vil det være muligt at generere en clien-class og en server-class, som kun kommunikerer vha. soap. Og altså, sender serveren kun de data til klienten, som klienten må se.

/B :)

Har du fået svar på dine spørgsmål?

læg et svar dem der føler sig beretiget til det, jeg kunne ikke bruge det til så meget :)

Jamen så har du jo åbenbart ikke fået svar på dit spørgsmål.

Det kan vi jo ikke vide hvis du ikke spørger ind til det vi skriver. Så spørg.

Jeg løste det ved at lærer hvordan man brugte klasse arving :-)

Det tog lige lidt tid at sætte mig ind i hvordan det skulle fungere med protected properties osv, men dete r sgu meget nyttigt..

Hvis nogen vil have point så smid et svar, tak for hjælpen

ok

Der skulle ikke have været delt her ?

hva mener du?