Umieszczanie kodu niestandardowego w przestrzeni nazw Systemu

Question

Czy istnieją jakieś sprawdzone metody, które powodują, że niestandardowy kod nie powinien znajdować się w przestrzeni nazw System? Czy powinno być zarezerwowane System i jego dzieci na kod Microsoft?

Pytam, ponieważ piszę bibliotekę klas, która będzie używana w wielu projektach i chciałbym zachować spójność, umieszczając ją w System.InteropServices (ponieważ dotyczy ona P/Invoke).

Answer 1

To nie jest dobry pomysł, ponieważ pokonuje jedną z głównych zalet przestrzeni nazw: zapobieganie konfliktom nazw. Co się stanie, jeśli nowsza wersja frameworku wprowadzi identyczny typ do tej przestrzeni nazw?

Jest to szczególnie szkodliwe dla System nazw ponieważ są one przywożone w wielu innych fragmentów kodu z using dyrektyw oraz wprowadzenie własnych typów w tych nazw zanieczyszcza zakresu nazewnictwa innych plików źródłowych z nieoczekiwanymi identyfikatorów.

Aby podzielić kategorie niestandardowych typów powiązanych z innymi, można utworzyć nowy obszar nazw, taki jak MyProduct.InteropServices.

Answer 2

Jeśli umieścisz nową klasę w System.InteropServices, każdy plik, który ma klauzulę using System.InteropServices;, musi mieć swoją klasę w zakresie, co może zmylić programistę. Ponieważ programista nie może się przed tym obronić, rozważałbym tę złą praktykę.

Answer 3

Nie zgadzam się ze wszystkimi.

Myślę, że w ograniczonym podzbiorze przypadków (głównie z metodami rozszerzającymi) uzasadnione jest umieszczanie kodu w przestrzeni nazw systemu.

Oto moja strona argumentu z gwintem email my debatującego rozszerzenie metod w przestrzeni nazw System na co EPS:

---

Ok, więc oto moja strona argumentu:

1. Bardzo lubię minimalizować kod. Dotyczy to również zastosowań.

2. Tak, ReSharper wybiera metody przedłużania i dodaje do ciebie użytek, ale niektórzy nie mają programu ReSharper, a poza tym wolę Coderusha, który jak dotąd nie jest (o ile wiem) odbierać rozszerzenia przestrzenie nazw.

3. Istnieją co najmniej dwa różne typy metod rozszerzenia; te, które są metodami pomocniczymi dla naszej aplikacji - w tym pomocników domen i aplikacji oraz tych, które zawierają elementy i składnię, które naszym zdaniem powinien zaczynać się od języka.

Przykładem tego ostatniego jest zdolność do "a {0} {1}".Format("b", "c") lub someListOfStrings.Join(", ") zamiast zrobić String.Join(someStringList.ToArray(), ", "). Inne bardziej dyskusyjne przykłady to IEnumerable<T>.ForEach i rozszerzenie IsNull(), które zajmuje miejsce niezręcznej składni object.ReferenceEquals(null, someVar).

Moim argumentem jest to, że istnieją wszelkie powody, aby umieścić tę ostatnią klasyfikację - Twój zespół zasadniczo zgadza się, że powinien być w języku, ale nie jest - w odpowiedniej przestrzeni nazw (System, System.IO, System.Linq itp.).Chcemy, aby te funkcje były dostępne wszędzie, tak jak wolimy foreach i słowa kluczowe, aby były zawsze widoczne. Jeśli jest to specyficzne dla aplikacji, powinno jednak iść w swoim własnym obszarze nazw. W 90% przypadków specyficzne dla aplikacji rozszerzenia pomocników najprawdopodobniej nie będą rozszerzeniami, a nawet nie będą statyczne. Wykluczam z tego oświadczenia za pomocą metod rozszerzających w celu zapewnienia aliasów dla nazw funkcji.

Możesz mieć pewne problemy z tym, oczywiście, podczas wywoływania złożeń, które zawierają rozszerzenia dla całego systemu. Przypuśćmy, że odwołuję się do zestawu zawierającego moją metodę void IEnumerable<T>.ForEach i chciałem stworzyć własną ruby-podobną do R IEnumerable<T, R>.ForEach (która jest właściwie tylko Select, ale nigdy nie myśl o tym). To byłby problem! To, co lubię robić, aby złagodzić problem, to zdefiniować moje klasy rozszerzeń jako wewnętrzne, aby mogły być używane tylko w moim projekcie. To ładnie rozwiązuje problem.