Egenskapsdesign
Kommentar
Det här innehållet skrivs om med behörighet från Pearson Education, Inc. från Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Den utgåvan publicerades 2008, och boken har sedan dess reviderats helt i den tredje utgåvan. En del av informationen på den här sidan kan vara inaktuell.
Även om egenskaper tekniskt sett liknar metoder är de helt olika när det gäller deras användningsscenarier. De bör ses som smarta fält. De har fältens anropssyntax och metodernas flexibilitet.
✔️ Skapa endast get-properties om anroparen inte ska kunna ändra värdet för egenskapen.
Tänk på att om egenskapens typ är en föränderlig referenstyp kan egenskapsvärdet ändras även om egenskapen endast är get-only.
❌ Ange INTE egenskaper för endast uppsättningar där settern har bredare tillgänglighet än gettern.
Använd till exempel inte egenskaper med en offentlig setter och en skyddad getter.
Om egenskaps getter inte kan tillhandahållas implementerar du funktionen som en metod i stället. Överväg att starta metodnamnet med Set och följa med vad du skulle ha namngett egenskapen. Till exempel AppDomain har en metod som heter SetCachePath i stället för att ha en set-only-egenskap som heter CachePath.
✔️ Ange lämpliga standardvärden för alla egenskaper, vilket säkerställer att standardvärdena inte resulterar i ett säkerhetshål eller en fruktansvärt ineffektiv kod.
✔️ Tillåt att egenskaper anges i valfri ordning även om detta resulterar i ett tillfälligt ogiltigt tillstånd för objektet.
Det är vanligt att två eller flera egenskaper kopplas till en punkt där vissa värden för en egenskap kan vara ogiltiga med tanke på värdena för andra egenskaper i samma objekt. I sådana fall bör undantag som uppstår på grund av det ogiltiga tillståndet skjutas upp tills de relaterade egenskaperna faktiskt används tillsammans av objektet.
✔️ Bevara det tidigare värdet om en egenskapsuppsättning utlöser ett undantag.
❌ UNDVIK att utlösa undantag från egenskapsmottagare.
Egenskapsmottagare bör vara enkla åtgärder och bör inte ha några förhandsvillkor. Om en getter kan utlösa ett undantag bör det förmodligen göras om till en metod. Observera att den här regeln inte gäller för indexerare, där vi förväntar oss undantag som ett resultat av att verifiera argumenten.
Design av indexerad egenskap
En indexerad egenskap är en särskild egenskap som kan ha parametrar och kan anropas med särskild syntax som liknar matrisindexering.
Indexerade egenskaper kallas ofta indexerare. Indexerare ska endast användas i API:er som ger åtkomst till objekt i en logisk samling. En sträng är till exempel en samling tecken och indexeraren på System.String har lagts till för att komma åt dess tecken.
✔️ ÖVERVÄG att använda indexerare för att ge åtkomst till data som lagras i en intern matris.
✔️ ÖVERVÄG att tillhandahålla indexerare för typer som representerar samlingar av objekt.
❌ UNDVIK att använda indexerade egenskaper med mer än en parameter.
Om designen kräver flera parametrar bör du överväga om egenskapen verkligen representerar en accessor till en logisk samling. Om den inte gör det använder du metoder i stället. Överväg att starta metodnamnet med Get eller Set.
❌ UNDVIK indexerare med andra parametertyper än System.Int32, System.Int64, System.String, System.Objecteller en uppräkning.
Om designen kräver andra typer av parametrar utvärderar du starkt om API:et verkligen representerar en accessor till en logisk samling. Om den inte gör det använder du en metod. Överväg att starta metodnamnet med Get eller Set.
✔️ Använd namnet Item för indexerade egenskaper om det inte finns ett uppenbart bättre namn (t.ex. se egenskapen på Chars[]System.String).
I C# heter indexerare som standard Objekt. IndexerNameAttribute Kan användas för att anpassa det här namnet.
❌ Ange INTE både en indexerare och metoder som är semantiskt likvärdiga.
❌ Ange INTE fler än en familj överlagrade indexerare i en typ.
Detta framtvingas av C#-kompilatorn.
❌ Använd INTE indexerade egenskaper utan fel.
Detta framtvingas av C#-kompilatorn.
Meddelandehändelser för egenskapsändring
Ibland är det användbart att ange en händelse som meddelar användaren om ändringar i ett egenskapsvärde. Till exempel System.Windows.Forms.Control genererar en TextChanged händelse när värdet för dess Text egenskap har ändrats.
✔️ ÖVERVÄG att skapa ändringsmeddelandehändelser när egenskapsvärden i högnivå-API:er (vanligtvis designerkomponenter) ändras.
Om det finns ett bra scenario för en användare att veta när en egenskap för ett objekt ändras, bör objektet skapa en ändringsmeddelandehändelse för egenskapen.
Det är dock osannolikt att det är värt att höja sådana händelser för lågnivå-API:er, till exempel bastyper eller samlingar. Skulle till exempel List<T> inte generera sådana händelser när ett nytt objekt läggs till i listan och Count egenskapen ändras.
✔️ ÖVERVÄG att skapa ändringsmeddelandehändelser när värdet för en egenskap ändras via externa krafter.
Om ett egenskapsvärde ändras via någon extern kraft (på ett annat sätt än genom att anropa metoder för objektet) anger höjningshändelser för utvecklaren att värdet ändras och har ändrats. Ett bra exempel är egenskapen för Text en textrutekontroll. När användaren skriver text i en TextBoxändras egenskapsvärdet automatiskt.
Portioner © 2005, 2009 Microsoft Corporation. Med ensamrätt.
Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, publicerad 22 okt 2008 av Addison-Wesley Professional som en del av Microsoft Windows Development Series.