Przestrzenie nazw w VB.NET

Klaus Vedfelt/Taxi/Getty Images

Najczęstszy sposób używania przestrzeni nazw VB.NET przez większość programiści jest poinformowanie kompilatora, które biblioteki .NET Framework są potrzebne dla konkretnego programu. Po wybraniu „szablonu” dla swojego projektu (takiego jak „Aplikacja Windows Forms”) jedną z wybranych rzeczy jest określony zestaw przestrzeni nazw, do których będzie automatycznie odwoływać się Twój projekt. Dzięki temu kod w tych przestrzeniach nazw jest dostępny dla twojego programu.

Na przykład niektóre przestrzenie nazw i rzeczywiste pliki, w których się znajdują dla aplikacji Windows Forms, to:

System > w System.dll
System.Data > w System.Data.dll
System.Deployment > System.Deployment.dll
System.Drawing > System.Drawing.dll
System.Windows.Forms > System.Windows.Forms.dll

Możesz zobaczyć (i zmienić) przestrzenie nazw i referencje dla swojego projektu we właściwościach projektu w obszarze Bibliografia patka.

Ten sposób myślenia o przestrzeniach nazw sprawia, że ​​wydają się one być tym samym, co „biblioteka kodu”, ale to tylko część pomysłu. Prawdziwą zaletą przestrzeni nazw jest organizacja.

Większość z nas nie będzie miała szansy na ustanowienie nowej hierarchii przestrzeni nazw, ponieważ zazwyczaj robi się to tylko raz „na początku” w przypadku dużej i skomplikowanej biblioteki kodu. Ale tutaj dowiesz się, jak interpretować przestrzenie nazw, o których użycie zostaniesz poproszony w wielu organizacjach.

Co robią przestrzenie nazw

Przestrzenie nazw umożliwiają organizowanie dziesiątek tysięcy obiektów .NET Framework i wszystkich obiektów, które programiści VB tworzą w projektach, aby nie kolidowały ze sobą.

Na przykład, jeśli szukasz .NET dla a Kolor obiekt, znajdziesz dwa. Tam jest Kolor obiekt w obu:

|_+_|

Jeśli dodasz Import oświadczenie dla obu przestrzeni nazw (odwołanie może być również konieczne dla właściwości projektu) ...

|_+_|

... potem stwierdzenie takie jak ...

|_+_|

... zostanie oznaczony jako błąd z dopiskiem „Kolor jest niejednoznaczny”, a .NET wskaże, że obie przestrzenie nazw zawierają obiekt o tej nazwie. Ten rodzaj błędu nazywa się „kolizją nazw”.

To jest prawdziwy powód „przestrzeni nazw”, a także sposób, w jaki przestrzenie nazw są używane w innych technologiach (takich jak XML). Przestrzenie nazw umożliwiają użycie tej samej nazwy obiektu, np. Kolor , gdy nazwa pasuje i nadal utrzymuje porządek. Możesz zdefiniować Kolor obiektu we własnym kodzie i trzymaj go oddzielnie od tych w .NET (lub w kodzie innych programistów).

|_+_|

Możesz także użyć Kolor obiekt w innym miejscu w twoim programie w ten sposób:

|_+_|

Zanim przejdziesz do niektórych innych funkcji, pamiętaj, że każdy projekt jest zawarty w przestrzeni nazw. VB.NET używa nazwy twojego projektu ( WindowsAplikacja1 dla aplikacji formularzy standardowych, jeśli go nie zmienisz) jako domyślną przestrzeń nazw. Aby to zobaczyć, utwórz nowy projekt (użyliśmy nazwy NSPros i wypróbuj narzędzie Przeglądarka obiektów):

1. Kliknij Tutaj aby wyświetlić ilustrację
2. Kliknij Z powrotem przycisk w przeglądarce, aby powrócić

Przeglądarka obiektów wyświetla nową przestrzeń nazw projektu (i automatycznie zdefiniowane w niej obiekty) wraz z przestrzeniami nazw .NET Framework. Ta zdolność VB.NET do uczynienia twoich obiektów równymi obiektom .NET jest jednym z kluczy do mocy i elastyczności. Na przykład dlatego Intellisense pokaże twoje własne obiekty, gdy tylko je zdefiniujesz.

Aby podnieść poprzeczkę, zdefiniujmy nowy projekt (Nazwaliśmy nasz NowyNSProj w tym samym rozwiązaniu (użyj Plik > Dodać > Nowy projekt ... ) i zakoduj nową przestrzeń nazw w tym projekcie. I żeby było fajniej, umieśćmy nową przestrzeń nazw w nowym module (nazwaliśmy go .) Nowy NSMod ). A ponieważ obiekt musi być zakodowany jako klasa, dodaliśmy również blok klasy (o nazwie NowyNSObj ). Oto kod i Eksplorator rozwiązań, aby pokazać, jak pasuje do siebie:

1. Kliknij Tutaj aby wyświetlić ilustrację
2. Kliknij Z powrotem przycisk w przeglądarce, aby powrócić

Ponieważ twój własny kod jest 'tak jak kod Framework', konieczne jest dodanie odwołania do Nowy NSMod w NSPros użyć obiektu w przestrzeni nazw, nawet jeśli znajdują się w tym samym rozwiązaniu. Gdy to zrobisz, możesz zadeklarować obiekt w NSPros w oparciu o metodę w Nowy NSMod . Musisz także „zbudować” projekt, aby istniał rzeczywisty obiekt, do którego można się odnieść.

|_+_|

To dość Ciemny oświadczenie choć. Możemy to skrócić, używając an Import oświadczenie z aliasem.

|_+_|

Kliknięcie przycisku Uruchom powoduje wyświetlenie MsgBox z przestrzeni nazw AVBNS: „Hej! Zadziałało!'

Kiedy i dlaczego używać przestrzeni nazw

Wszystko do tej pory tak naprawdę po prostu było składnia - kodowanie zasady, których musisz przestrzegać używając przestrzeni nazw. Ale aby naprawdę skorzystać, potrzebujesz dwóch rzeczy:

• Przede wszystkim wymóg organizacji przestrzeni nazw. Potrzebujesz czegoś więcej niż tylko projektu „Hello World”, zanim organizacja przestrzeni nazw zacznie się opłacać.
• Plan ich wykorzystania.

Ogólnie, Microsoft zaleca zorganizowanie kodu organizacji przy użyciu kombinacji nazwy firmy z nazwą produktu.

Na przykład, jeśli jesteś głównym architektem oprogramowania w firmie Dr No's Nose Knows Plastic Surgery, możesz uporządkować swoje przestrzenie nazw, tak jak ...

|_+_|

Jest to podobne do organizacji .NET ...

|_+_|

Wielopoziomowe przestrzenie nazw są osiągane przez proste zagnieżdżanie bloków przestrzeni nazw.

|_+_|

lub

|_+_|