Verificatie van gegevens in Getter / Setter of elders?

stemmen
9

Ik vraag me af of het een goed idee om ervoor verificaties in getters en setters , of elders in de code.

Dit kan u verrassen als het gaat om optimalisaties en het versnellen van de code, ik denk dat je moet niet verificaties verricht in getters en setters, maar in de code waar je het updaten van uw bestanden of database. Heb ik het fout?

De vraag is gesteld op 05/08/2008 om 20:51
bron van user
In andere talen...                            


8 antwoorden

stemmen
13

Nou, een van de reaons waarom klassen meestal particuliere leden bevatten met publiek getters / setters is precies omdat ze gegevens kunnen controleren.

Als u een nummer dan kan tussen 1 en 100, zou ik zeker iets in de setter dat valideert en dan misschien een uitzondering die wordt gevangen door de code. De reden is simpel: Als je het niet in de zetter doet, je moet niet vergeten dat 1 tot 100 beperking elke keer dat je in te stellen, wat leidt tot gedupliceerde code of wanneer u het vergeet, het leidt tot een ongeldige status.

Wat betreft prestaties, ik ben met Knuth hier:

"We moeten vergeten kleine efficiëntie, zeg ongeveer 97% van de tijd. Vroegtijdige optimalisatie is de wortel van alle kwaad"

antwoordde op 05/08/2008 om 20:59
bron van user

stemmen
4

@Terrapin, re:

Als alles wat je hebt is een bos van [eenvoudige publieke set / get] eigenschappen ... ze kan net zo goed velden

Eigenschappen hebben ook andere voordelen over de velden. Ze zijn een meer expliciete opdracht, ze zijn serialized, kunnen ze later worden opgespoord, zijn ze een leuke plek voor uitbreiding door middel van overerving. De clunkier syntax is een toevallige complexiteit - NET 3.5 bijvoorbeeld deze overwint.

Een veel voorkomende (en gebrekkig) praktijk is om te beginnen met de publieke velden, en zet ze in eigenschappen later, op een 'zo nodig' basis. Dit breekt uw contract met iedereen die je klas verbruikt, dus het is best om te beginnen met eigenschappen.

antwoordde op 08/08/2008 om 01:07
bron van user

stemmen
3

Het hangt er van af.

In het algemeen moet de code snel mislukken. Als de waarde van meerdere punten in de code kan worden ingesteld en u valideren pas na het ophalen van de waarde, wordt de bug te zijn in de code die de update doet. Als de setters valideren van de input, weet je wat code probeert om ongeldige waarden in te stellen.

antwoordde op 05/08/2008 om 20:59
bron van user

stemmen
3

Vanuit het perspectief van het hebben van de meest onderhoudbare code, ik denk dat je moet zo veel validatie doen als je kunt in de setter van een woning. Op deze manier zul je niet worden caching of anderszins omgaan met ongeldige gegevens.

Immers, dit is wat woningen zijn bedoeld voor. Als alles wat je hebt is een bos van eigenschappen, zoals ...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

... ze kan net zo goed velden

antwoordde op 05/08/2008 om 20:59
bron van user

stemmen
1

Ik probeer nooit laat mijn voorwerpen in een ongeldige toestand, zodat setters zou zeker validatie hebben alsmede alle methoden die toestand te veranderen. Op deze manier heb ik nooit zorgen te maken dat het object ik te maken heb is ongeldig. Als u uw methoden valideren grenzen te houden, dan moet je nooit zorgen te maken over de validatie kaders en IsValid () methode oproepen gestrooid all over the place.

antwoordde op 23/09/2008 om 20:44
bron van user

stemmen
1

Ik wil implementeren IDataErrorInfo en mijn validatielogica in de fout en deze [columnName] eigenschappen. Op die manier als je wilt programmatisch controleren of er is een fout kun je gewoon een van die eigenschappen te testen in de code, of u kunt de validatie hand uit om de gegevens te binden in webformulieren, Windows Forms en WPF.

WPF "ValidatesOnDataError" bindende eigenschap maakt deze bijzonder eenvoudig.

antwoordde op 07/08/2008 om 23:24
bron van user

stemmen
1

Misschien moet je check out Domain Driven Design , door Eric Evans. DDD heeft dit idee van een Specificatie:

... expliciete predikaat-achtige waardevolle objecten voor speciale doeleinden. Een specificatie is een predikaat dat bepaalt of een voorwerp al dan niet voldoet aan bepaalde criteria.

Ik denk dat het niet snel is één ding, de andere is waar de logica voor validatie te houden. Het domein is de juiste plaats om de logica te houden en ik denk dat een specificatie Object of een validate methode op uw domein objecten zou een goede plek zijn.

antwoordde op 05/08/2008 om 21:03
bron van user

stemmen
1

Validatie moet afzonderlijk worden vastgelegd van getters en setters in een validatie methode. Op die manier als de validatie moet worden hergebruikt voor meerdere componenten, deze beschikbaar is.

Wanneer de aanbrenginrichting wordt genoemd, dient een dergelijke validatieservice worden gebruikt voor het invoeren ontsmetten in het voorwerp. Op die manier weet je alle informatie die is opgeslagen in een object is geldig op alle tijden.

Je hoeft niet elke vorm van validatie van de getter nodig, omdat de informatie over het object reeds wordt vertrouwd geldig te zijn.

Laat uw validatie niet opslaan totdat er een database update !! Het is beter om snel mislukken .

antwoordde op 05/08/2008 om 20:55
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more