Tulajdonságtervezés
Feljegyzés
Ezt a tartalmat a Pearson Education, Inc. engedélyével nyomtatjuk újra a Framework Design Guidelines: Conventions, Idioms és Patterns for Reusable .NET Libraries, 2nd Edition engedélyével. Ezt a kiadást 2008-ban adták ki, és a könyvet azóta teljesen átdolgozták a harmadik kiadásban. Előfordulhat, hogy az oldalon található információk némelyike elavult.
Bár a tulajdonságok technikailag nagyon hasonlítanak a metódusokhoz, használati forgatókönyveikben meglehetősen eltérőek. Ezeket intelligens mezőknek kell tekinteni. A mezők hívó szintaxisával és a metódusok rugalmasságával rendelkeznek.
✔️ NE hozzon létre csak lekéréses tulajdonságokat, ha a hívónak nem kell tudnia módosítani a tulajdonság értékét.
Ne feledje, hogy ha a tulajdonság típusa egy módosítható hivatkozástípus, akkor a tulajdonság értéke akkor is módosítható, ha a tulajdonság csak lekéréses.
❌ NE adjon meg csak beállítási tulajdonságokat vagy tulajdonságokat a beállítónál szélesebb körű akadálymentességgel.
Például ne használjon tulajdonságokat nyilvános beállítóval és védett getterrel.
Ha a tulajdonságbeolvasó nem adható meg, implementálja inkább metódusként a funkciót. Fontolja meg a metódus nevét Set , és kövesse azt, amit a tulajdonságnak elnevezett volna. Például egy metódust hívunk SetCachePath meg ahelyett, AppDomain hogy egy csak set-only tulajdonságot hívunkCachePath.
✔️ A DO minden tulajdonsághoz ésszerű alapértelmezett értékeket biztosít, így az alapértelmezett értékek nem eredményeznek biztonsági rést vagy nem hatékony kódot.
✔️ A DO lehetővé teszi, hogy a tulajdonságok bármilyen sorrendben legyenek beállítva, még akkor is, ha ez az objektum ideiglenes érvénytelen állapotát eredményezi.
Gyakran előfordul, hogy két vagy több tulajdonság egy olyan ponttal van összefüggésben, ahol az egyik tulajdonság egyes értékei érvénytelenek lehetnek az ugyanazon objektumon található egyéb tulajdonságok értékei miatt. Ilyen esetekben az érvénytelen állapotból eredő kivételeket el kell halasztani addig, amíg az objektum ténylegesen együtt nem használja az egymással összefüggő tulajdonságokat.
✔️ NE őrizze meg az előző értéket, ha egy tulajdonsághalmaz kivételt jelez.
❌ KERÜLJE a kivételeket a tulajdonságbeolvasóktól.
A tulajdonságleíróknak egyszerű műveleteknek kell lenniük, és nem lehetnek előfeltételeik. Ha egy getter kivételt tud kivenni, akkor valószínűleg újra kell tervezni, hogy metódus legyen. Figyelje meg, hogy ez a szabály nem vonatkozik az indexelőkre, ahol kivételeket várunk az argumentumok érvényesítése miatt.
Indexelt tulajdonság tervezése
Az indexelt tulajdonság egy speciális tulajdonság, amely paraméterekkel rendelkezhet, és a tömbindexeléshez hasonló speciális szintaxissal hívható meg.
Az indexelt tulajdonságokat gyakran indexelőknek nevezzük. Az indexelőket csak olyan API-kban szabad használni, amelyek hozzáférést biztosítanak egy logikai gyűjtemény elemeihez. Egy sztring például egy karaktergyűjtemény, és az indexelő System.String hozzá lett adva a karakterek eléréséhez.
✔️ FONTOLJA meg, hogy indexelőkkel biztosítson hozzáférést egy belső tömbben tárolt adatokhoz.
✔️ FONTOLJA meg, hogy az elemgyűjteményeket képviselő típusok indexelőit adja meg.
❌ NE használjon indexelt tulajdonságokat egynél több paraméterrel.
Ha a kialakítás több paramétert igényel, gondolja át, hogy a tulajdonság valóban egy logikai gyűjtemény kiegészítője-e. Ha nem, használjon inkább metódusokat. Érdemes lehet elindítani a metódus nevét a következővel Get : vagy Set.
❌ KERÜLJE az olyan indexelőket, amelyek nem System.Int32, System.Int64, , System.String, System.Objectvagy enum paramétertípusokkal rendelkeznek.
Ha a kialakítás más típusú paramétereket igényel, értékelje újra, hogy az API valóban egy logikai gyűjtemény kiegészítője-e. Ha nem, használjon egy metódust. Érdemes lehet elindítani a metódus nevét a következővel Get : vagy Set.
✔️ A DO az indexelt tulajdonságok nevét Item használja, hacsak nincs nyilvánvalóan jobb név (például lásd a Chars[] tulajdonságot a következőn System.String).
A C#-ban az indexelők alapértelmezés szerint Elem néven vannak elnevezve. Ez IndexerNameAttribute a név testre szabható.
❌ NE adjon meg olyan indexelőt és metódust, amely szemantikailag egyenértékű.
❌ NE adjon meg egynél több túlterhelt indexelőcsaládot egy típusban.
Ezt a C#-fordító kényszeríti.
❌ NE használjon nem megbízható indexelt tulajdonságokat.
Ezt a C#-fordító kényszeríti.
Tulajdonságváltozás-értesítési események
Néha hasznos olyan eseményt biztosítani, amely értesíti a felhasználót egy tulajdonságérték változásairól. Egy eseményt például azután hoz létreTextChanged, System.Windows.Forms.Control hogy a tulajdonság értéke Text megváltozott.
✔️ Érdemes lehet módosítani a változásértesítési eseményeket, ha a tulajdonságértékek a magas szintű API-kban (általában tervezőösszetevőkben) módosulnak.
Ha egy felhasználónak van egy jó forgatókönyve, amelyből megtudhatja, hogy egy objektum tulajdonsága mikor változik, az objektumnak változásértesítési eseményt kell létrehoznia a tulajdonsághoz.
Az alacsony szintű API-k, például alaptípusok vagy gyűjtemények esetében azonban nem érdemes többletterhelést okozni. Például nem hozna létre ilyen eseményeket, List<T> ha új elemet ad hozzá a listához, és a Count tulajdonság megváltozik.
✔️ Fontolja meg a változásértesítési események növelését, ha egy tulajdonság értéke külső erőkkel változik.
Ha egy tulajdonság értéke valamilyen külső erőn (az objektum metódusainak meghívásán kívül) megváltozik, az események a fejlesztő számára azt jelzik, hogy az érték változik, és megváltozott. Jó példa egy Text szövegdoboz vezérlőelem tulajdonságára. Amikor a felhasználó szöveget ír be egy TextBoxfájlba, a tulajdonság értéke automatikusan megváltozik.
© Részletek 2005, 2009 Microsoft Corporation. Minden jog fenntartva.
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, published 22, 2008 by Addison-Wesley Professional, a Microsoft Windows Development Series részeként.