Změny způsobující chyby
Pro knihovnu .NET je důležité najít rovnováhu mezi stabilitou stávajících uživatelů a inovací pro budoucnost. Autoři knihoven se přikláněli k refaktoringu a přemýšlení kódu, dokud nebude dokonalý, ale porušení stávajících uživatelů má negativní dopad, zejména pro knihovny nízké úrovně.
Typy projektů a zásadní změny
Způsob, jakým komunita .NET používá knihovnu, mění vliv zásadních změn na vývojáře koncových uživatelů.
Knihovny nízké a střední úrovně , jako je serializátor, analyzátor HTML, mapovač relačních databázových objektů nebo webová architektura, jsou nejvíce ovlivněné zásadními změnami.
Balíčky stavebních bloků používají vývojáři koncových uživatelů k vytváření aplikací a dalších knihoven jako závislostí NuGet. Například vytváříte aplikaci a k volání webové služby používáte opensourcového klienta. Zásadní aktualizace závislosti, kterou klient používá, není něco, co můžete opravit. Je to opensourcový klient, který je potřeba změnit a nemáte nad ním žádnou kontrolu. Musíte najít kompatibilní verze knihoven nebo odeslat opravu do klientské knihovny a počkat na novou verzi. Nejhorší situace je, když chcete použít dvě knihovny, které závisí na vzájemně nekompatibilních verzích třetí knihovny.
Knihovny vysoké úrovně, jako je sada ovládacích prvků uživatelského rozhraní, jsou méně citlivé na zásadní změny.
Na knihovny vysoké úrovně se přímo odkazuje v aplikaci koncového uživatele. Pokud dojde k zásadním změnám, vývojář se může rozhodnout aktualizovat na nejnovější verzi nebo může upravit aplikaci tak, aby fungovala se změnou způsobující chybu.
✔️ Zamyslete se nad tím, jak se vaše knihovna bude používat. Jaký vliv bude mít zásadní vliv na aplikace a knihovny, které je používají?
✔️ Minimalizujte zásadní změny při vývoji knihovny .NET nízké úrovně.
✔️ ZVAŽTE publikování hlavního přepsání knihovny jako nového balíčku NuGet.
Typy zásadních změn
Rozbíjející změny spadají do různých kategorií a nejsou stejně ovlivněné.
Změna způsobující chybu zdroje
Změna způsobující chybu zdroje nemá vliv na provádění programu, ale při příštím překompilování aplikace způsobí chyby kompilace. Například nové přetížení může vytvořit nejednoznačnost volání metody, která byla jednoznačná dříve, nebo přejmenovaný parametr přeruší volající, kteří používají pojmenované parametry.
public class Task
{
// Adding a type called Task could conflict with System.Threading.Tasks.Task at compilation
}
Vzhledem k tomu, že změna způsobující chybu zdroje je škodlivá jenom v případě, že vývojáři překompilují své aplikace, jedná se o nejméně rušivý zásadní změnu. Vývojáři můžou snadno opravit svůj vlastní poškozený zdrojový kód.
Změna způsobující chování
Změny chování jsou nejběžnějším typem zásadní změny: téměř jakákoli změna chování může způsobit chybu logiky pro příjemce. Změny v knihovně, jako jsou podpisy metod, výjimky vyvolané nebo formáty vstupních nebo výstupních dat, můžou negativně ovlivnit uživatele knihovny. I oprava chyby se může kvalifikovat jako změna způsobující chybu, pokud se uživatelé spoléhali na dříve poškozené chování.
Přidání funkcí a zlepšení špatného chování je dobrá věc, ale bez opatrnosti může být pro stávající uživatele velmi obtížné upgradovat. Jedním z přístupů, jak vývojářům pomoct řešit změny způsobující chování, je skrýt je za nastavením. Nastavení umožnit vývojářům aktualizovat na nejnovější verzi knihovny a zároveň se rozhodnout, že se přihlásí nebo se odhlásí od zásadních změn. Díky této strategii můžou vývojáři zůstat v aktualizovaném stavu a nechat jejich náročný kód se v průběhu času přizpůsobovat.
Například ASP.NET Core MVC má koncept verze kompatibility, která upravuje povolené a zakázané MvcOptionsfunkce .
✔️ ZVAŽTE, jestli nové funkce ve výchozím nastavení nemají vliv na stávající uživatele, a nechte vývojáře, aby se k této funkci přihlásili pomocí nastavení.
Další informace o změnách způsobujících chování v rozhraních .NET API naleznete v tématu Kompatibilita změn chování .NET.
Binární změna způsobující chybu
Při změně veřejného rozhraní API knihovny dojde k binární zásadní změně, takže sestavení zkompilovaná ve starších verzích knihovny už nebudou moct rozhraní API volat. Například změna podpisu metody přidáním nového parametru způsobí, že sestavení zkompilovaná ve starší verzi knihovny vyvolá MissingMethodExceptionvýjimku .
Binární změna způsobující chybu může také přerušit celé sestavení. Přejmenováním sestavení AssemblyName se změní identita sestavení, stejně jako přidání, odebrání nebo změna silného klíče pojmenování sestavení. Změna identity sestavení přeruší veškerý zkompilovaný kód, který ho používá.
❌ NEMĚŇTE název sestavení.
❌ NEPŘIDÁVEJTE, odebírat ani měnit silný klíč pro pojmenování.
✔️ ZVAŽTE použití abstraktních základních tříd místo rozhraní.
Přidání čehokoli do rozhraní způsobí selhání existujících typů, které ho implementují. Abstraktní základní třída umožňuje přidat výchozí virtuální implementaci.
✔️ ZVAŽTE umístění ObsoleteAttribute typů a členů, které chcete odebrat. Atribut by měl obsahovat pokyny pro aktualizaci kódu, aby už zastaralé rozhraní API nepoužít.
Kód, který volá typy a metody pomocí ObsoleteAttribute vygeneruje upozornění sestavení se zprávou zadanou atributem. Upozornění poskytují uživatelům, kteří používají zastaralý čas k migraci rozhraní API, aby se po odebrání zastaralého rozhraní API přestalo používat.
public class Document
{
[Obsolete("LoadDocument(string) is obsolete. Use LoadDocument(Uri) instead.")]
public static Document LoadDocument(string uri)
{
return LoadDocument(new Uri(uri));
}
public static Document LoadDocument(Uri uri)
{
// Load the document
}
}
✔️ ZVAŽTE zachování typů a metod s ObsoleteAttribute neomezenou dobou v knihovnách nízké a střední úrovně.
Odebrání rozhraní API je binární zásadní změna. Zvažte zachování zastaralých typů a metod, pokud je udržujete nízké náklady a nepřidávejte do knihovny velké množství technického dluhu. Odebráním typů a metod se můžete vyhnout výše uvedeným scénářům nejhoršího případu.
Další informace o tom, jaké změny rozhraní .NET API přeruší binární kompatibilitu, naleznete v tématu Kompatibilita veřejných kontraktů .NET.
