Návrh parametru

Poznámka:

Tento obsah je znovu vytištěn oprávněním Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms a Patterns for Reusable .NET Libraries, 2. vydání. Tato edice byla publikována v roce 2008 a kniha byla od té doby plně upravena ve třetím vydání. Některé informace na této stránce můžou být zastaralé.

Tato část obsahuje obecné pokyny k návrhu parametrů, včetně oddílů s pokyny pro kontrolu argumentů. Kromě toho byste se měli odkazovat na pokyny popsané v Pojmenování parametrů.

✔️ Použijte nejméně odvozený typ parametru, který poskytuje funkce vyžadované členem.

Předpokládejme například, že chcete navrhnout metodu, která vytvoří výčet kolekce a vytiskne každou položku do konzoly. Taková metoda by měla mít jako parametr IEnumerable, například ne ArrayList nebo IList.

❌ NEPOUŽÍVEJTE rezervované parametry.

Pokud je v nějaké budoucí verzi potřeba další vstup pro člena, lze přidat nové přetížení.

❌ NEMAJÍ veřejně vystavené metody, které jako parametry přijímají ukazatele, pole ukazatelů nebo multidimenzionální pole.

Ukazatele a multidimenzionální pole jsou poměrně obtížné správně používat. V téměř všech případech je možné přepracovat rozhraní API, aby se zabránilo tomu, že tyto typy použijete jako parametry.

✔️ Umístěte všechny out parametry za všechny parametry podle hodnoty a ref parametry (s výjimkou polí parametrů), i když to vede k nekonzistenci v pořadí parametrů mezi přetíženími (viz Přetížení člena).

Parametry out lze považovat za dodatečné návratové hodnoty a jejich seskupení usnadňuje pochopení podpisu metody.

✔️ Při přepsání členů nebo implementaci členů rozhraní buďte konzistentní v pojmenování parametrů.

To lépe komunikuje vztah mezi metodami.

Volba mezi výčtem a logickými parametry

✔️ POUŽIJTE výčty, pokud by člen jinak měl dva nebo více logických parametrů.

❌ Nepoužívejte booleovské hodnoty, pokud si nejste naprosto jistí, že nikdy nebude potřeba více než dvě hodnoty.

Výčty poskytují prostor pro budoucí sčítání hodnot, ale měli byste vědět o všech dopadech přidávání hodnot do výčtů, které jsou popsány v návrhu výčtu.

✔️ ZVAŽTE použití logických hodnot pro parametry konstruktoru, které jsou skutečně dvoustavové hodnoty a jsou jednoduše použity k inicializaci logických vlastností.

Ověřování argumentů

✔️ Ověřte argumenty předávané veřejným, chráněným nebo explicitně implementovaným členům. Vyvolejte System.ArgumentException nebo jednu z jejích podtříd, pokud se ověření nezdaří.

Všimněte si, že skutečné ověření nemusí nutně probíhat přímo ve veřejném nebo chráněném členu. Může k tomu dojít na nižší úrovni v některé privátní nebo interní rutině. Hlavním bodem je, že celý povrch, který je vystaven koncovým uživatelům, kontroluje argumenty.

✔️ Vyvolejte výjimku ArgumentNullException, pokud je předán argument null a člen nepodporuje argumenty null.

✔️ VALIDUJTE parametry výčtu.

Nepředpokládejte, že argumenty výčtu budou v rozsahu definovaném výčtem. CLR umožňuje převod libovolné celočíselné hodnoty na hodnotu výčtu, i když tato hodnota není definována ve výčtu.

❌ NEPOUŽÍVEJTE Enum.IsDefined ke kontrolám rozsahu výčtů.

✔️ Mějte na paměti, že po ověření mohly být změněny proměnlivé argumenty.

Pokud je člen citlivý na zabezpečení, doporučujeme vytvořit kopii a pak ověřit a zpracovat argument.

Předávání parametrů

Z pohledu návrháře architektury existují tři hlavní skupiny parametrů: parametry podle hodnoty, ref parametry a out parametry.

Pokud je argument předán parametrem podle hodnoty, člen obdrží kopii skutečného argumentu předaného. Pokud je argumentem typ hodnoty, vloží se do zásobníku kopie argumentu. Pokud je argumentem typ odkazu, vloží se do zásobníku kopie odkazu. Nejoblíbenější jazyky CLR, jako je C#, VB.NET a C++, mají výchozí hodnotu předávání parametrů podle hodnoty.

Když je argument předán prostřednictvím parametru ref , člen obdrží odkaz na skutečný argument předaný. Pokud je argumentem typ hodnoty, odkaz na tento argument se vloží do zásobníku. Pokud je argument typu odkazu, objekt typu odkazu se umístí do zásobníku. Ref Parametry lze použít k tomu, aby člen mohl upravovat argumenty předané volajícím.

Out parametry jsou podobné ref parametrům, s některými malými rozdíly. Parametr je zpočátku považován za nepřiřazený a nelze jej přečíst v rámci členové části, dokud mu není přiřazena nějaká hodnota. Také musí být parametru přiřazena nějaká hodnota před návratem prvku.

❌ Vyhněte se používání out nebo ref parametrů.

Použití out nebo ref parametry vyžaduje zkušenosti s ukazateli, pochopení, jak se typy hodnot a odkazové typy liší, a zpracování metod s více návratovými hodnotami. Rozdíl mezi parametry out a ref také není široce pochopen. Architekti architektury, kteří navrhují pro širokou cílovou skupinu, by neměli očekávat, že uživatelé budou mít zkušenosti při práci s out parametry nebo ref parametry.

❌ NEPŘEDÁVEJTE odkazové typy jako odkazový parametr.

Existují určité omezené výjimky z pravidla, například metoda, kterou lze použít k výměně odkazů.

Členy s proměnným počtem parametrů

Členové, kteří mohou přijmout proměnný počet argumentů jsou vyjádřeny zadáním parametru pole. Například String poskytuje následující metodu:

public class String {
    public static string Format(string format, object[] parameters);
}

Uživatel pak může metodu String.Format volat následujícím způsobem:

String.Format("File {0} not found in {1}",new object[]{filename,directory});

Přidání klíčového slova params jazyka C# k parametru pole změní parametr na tzv. parametr typu params a poskytne jednoduchý způsob pro vytvoření dočasného pole.

public class String {
    public static string Format(string format, params object[] parameters);
}

Tím umožníte uživateli volat metodu předáním prvků pole přímo v seznamu argumentů.

String.Format("File {0} not found in {1}",filename,directory);

Všimněte si, že klíčové slovo parametru lze přidat pouze k poslednímu parametru v seznamu parametrů.

✔️ Zvažte přidání klíčového slova parametru do parametrů pole, pokud očekáváte, že koncoví uživatelé předávají pole s malým počtem prvků. Pokud se očekává, že v běžných scénářích bude předáno velké množství prvků, uživatelé pravděpodobně nebudou tyto prvky předávat přímo, takže klíčové slovo params není nutné.

❌ Nepoužívejte pole parametrů, pokud by volající téměř vždy měl vstup již v poli.

Členové s parametry pole bajtů by například téměř nikdy nebyli volány předáním jednotlivých bajtů. Z tohoto důvodu nepoužívají parametry bajtového pole v rozhraní .NET Framework klíčové slovo params.

❌ NEPOUŽÍVEJTE pole parametrů, pokud je pole změněno členem, který přebírá parametr pole parametrů.

Vzhledem k tomu, že mnoho kompilátorů změní argumenty na člena na dočasné pole v lokalitě volání, může být pole dočasným objektem, a proto všechny změny pole budou ztraceny.

✔️ ZVAŽTE použití klíčového slova params pro jednoduché přetížení, i když složitější přetížení by ho nemohlo použít.

Zeptejte se sami sebe, zda by uživatelé považovali za užitečné mít pole parametrů v jednom přetížení, i když by nebylo ve všech přetíženích.

✔️ Zkuste uspořádat parametry, aby bylo možné použít klíčové slovo params.

✔️ ZVAŽTE poskytnutí speciálních přetížení a větví kódu pro volání s malým počtem argumentů v rozhraních API extrémně citlivých na výkon.

Díky tomu se můžete vyhnout vytváření maticových objektů při volání rozhraní API s malým počtem argumentů. Názvy parametrů vytvořte tak, že vezmete jednotný tvar parametru pole a přidáte číselnou příponu.

Měli byste to provést pouze v případě, že budete provádět speciální případ celé cesty kódu, ne jen vytvořit pole a volat obecnější metodu.

✔️ Mějte na paměti, že hodnotu null lze předat jako argument pole parametrů.

Před zpracováním byste měli ověřit, že pole nemá hodnotu null.

❌ NEPOUŽÍVEJTE varargs metody, jinak známé jako elipsy.

Některé jazyky CLR, například C++, podporují alternativní konvenci pro předávání seznamů parametrů proměnných označovaných jako varargs metody. Konvence by se neměla používat v architekturách, protože není kompatibilní se specifikací CLS.

Parametry ukazatele

Obecně platí, že ukazatele by se neměly zobrazovat ve veřejné ploše dobře navržené spravované architektury kódu. Ve většině případů by se ukazatele měly zapouzdřovat. V některých případech jsou však ukazatele vyžadovány z důvodů interoperability a použití ukazatelů v takových případech je vhodné.

✔️ Poskytněte alternativu pro jakýkoli člen, který přebírá argument ukazatele, protože ukazatele nejsou kompatibilní se specifikací CLS.

❌ Vyhněte se provádění nákladné kontroly argumentů ukazatele.

✔️ Při návrhu členů pomocí ukazatelů postupujte podle běžných konvencí souvisejících s ukazateli.

Například není nutné předat počáteční index, protože jednoduchý aritmetický ukazatel lze použít k dosažení stejného výsledku.

Přetištěno se svolením Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition od Krzysztofa Cwaliny a Brada Abramse, vydáno 22. října 2008 nakladatelstvím Addison-Wesley Professional jako součást série Microsoft Windows Development.

Viz také

Last updated on 2025-06-17