Najpopularniejszy sposób, w jaki większość używa przestrzeni nazw VB.NET programiści jest poinformowanie kompilatora, które biblioteki .NET Framework są potrzebne dla konkretnego programu. Gdy wybierzesz „szablon” dla swojego projektu (np. „Aplikacja Windows Forms”), jedną z rzeczy wybierasz konkretny zestaw przestrzeni nazw, do których będzie się automatycznie odwoływać projekt. Dzięki temu kod w tych przestrzeniach nazw będzie dostępny dla twojego programu.
Na przykład niektóre przestrzenie nazw i rzeczywiste pliki, w których znajdują się dla aplikacji Windows Forms:
System> w System.dll
System. Dane> w systemie. Data.dll
System. Wdrażanie> System. Deployment.dll
System. Rysowanie> System. Drawing.dll
System. Windows Formularze> System. Windows Forms.dll
Możesz zobaczyć (i zmienić) przestrzenie nazw i referencje dla twojego projektu we właściwościach projektu pod Bibliografia patka.
Ten sposób myślenia o przestrzeniach nazw sprawia, że wydają się one być tym samym co „biblioteka kodów”, ale to tylko część pomysłu. Prawdziwą zaletą przestrzeni nazw jest organizacja.
Większość z nas nie ma szansy na ustanowienie nowej hierarchii przestrzeni nazw, ponieważ jest to generalnie wykonywane tylko raz „na początku” w przypadku dużej i skomplikowanej biblioteki kodów. Ale tutaj nauczysz się interpretować przestrzenie nazw, których będziesz musiał używać w wielu organizacjach.
Co robią przestrzenie nazw
Przestrzenie nazw umożliwiają organizację dziesiątek tysięcy obiektów .NET Framework i wszystkich obiektów tworzonych przez programistów VB w projektach, aby się nie kolidowały.
Na przykład, jeśli wyszukujesz .NET w poszukiwaniu Kolor obiekt, znajdziesz dwa. Tam jest Kolor obiekt w obu:
System. Rysunek
System. Windows Głoska bezdźwięczna
Jeśli dodasz Import instrukcja dla obu przestrzeni nazw (może być konieczne odniesienie do właściwości projektu) ...
System importu. Rysunek
System importu. Windows Głoska bezdźwięczna
... następnie stwierdzenie takie jak ...
Przyciemnij kolor
... zostanie oznaczony jako błąd z informacją „Kolor jest niejednoznaczny”, a .NET zwróci uwagę, ż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ą wykorzystywane 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 obiekt we własnym kodzie i trzymaj go odrębny od tych w .NET (lub kodzie innych programistów).
Przestrzeń nazw MyColor
Kolor klasy publicznej
Sub Color ()
' Zrób coś
Napis końcowy
Klasa końcowa
Koniec przestrzeni nazw
Możesz także użyć Kolor obiekt w innym miejscu twojego programu, taki jak ten:
Dim c As New MyColor. Kolor
do. Kolor()
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 (Aplikacja Windows 1 dla standardowej aplikacji formularzy, jeśli jej nie zmienisz) jako domyślnej przestrzeni nazw. Aby to zobaczyć, utwórz nowy projekt (użyliśmy nazwy NSProj i sprawdź narzędzie Object Browser):
- Kliknij Tutaj aby wyświetlić ilustrację
- Kliknij Plecy przycisk w przeglądarce, aby wrócić
Przeglądarka obiektów pokazuje twoją nową przestrzeń nazw projektu (i automatycznie zdefiniowane 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 siły i elastyczności. Na przykład dlatego Intellisense pokaże własne obiekty, jak tylko je zdefiniujesz.
Aby podnieść poprzeczkę, zdefiniujmy nowy projekt (nazwaliśmy nasz NewNSProj w tym samym rozwiązaniu (użyj Plik > Dodaj > Nowy projekt ...) i kod nowej przestrzeni nazw w tym projekcie. Żeby było zabawniej, umieśćmy nową przestrzeń nazw w nowym module (nazwaliśmy ją NewNSMod). A ponieważ obiekt musi być zakodowany jako klasa, dodaliśmy również blok klasy (o nazwie NewNSObj). Oto kod i Eksplorator rozwiązań, które pokazują, jak to pasuje:
- Kliknij Tutaj aby wyświetlić ilustrację
- Kliknij Plecy przycisk w przeglądarce, aby wrócić
Ponieważ twój własny kod jest „podobny do kodu frameworka”, konieczne jest dodanie odwołania do NewNSMod w NSProj aby użyć obiektu w przestrzeni nazw, nawet jeśli są w tym samym rozwiązaniu. Gdy to zrobisz, możesz zadeklarować obiekt w NSProj oparty na metodzie w NewNSMod. Musisz także „zbudować” projekt, aby istniał rzeczywisty obiekt do odwołania.
Dim o As New NewSPSP. AVBNS.NewNSMod. NewNSObj
o. AVBNSMethod ()
To całkiem Ciemny oświadczenie. Możemy to skrócić, używając Import instrukcja z aliasem.
Importuje NS = NewNSProj. AVBNS.NewNSMod. NewNSObj
...
Dim o As New NS
o. AVBNSMethod ()
Kliknięcie przycisku Uruchom wyświetla MsgBox z przestrzeni nazw AVBNS „Hej! Zadziałało!"
Kiedy i dlaczego używać przestrzeni nazw
Wszystko do tej pory było naprawdę składnia - kodowanie zasady, których musisz przestrzegać podczas korzystania z przestrzeni nazw. Ale aby naprawdę skorzystać, potrzebujesz dwóch rzeczy:
- Przede wszystkim wymóg organizacji przestrzeni nazw. Potrzebujesz więcej niż projektu „Hello World”, zanim organizacja przestrzeni nazw zacznie się opłacać.
- Plan ich wykorzystania.
Ogólnie, Microsoft zaleca uporządkowanie kodu organizacji przy użyciu kombinacji nazwy firmy i nazwy produktu.
Na przykład, jeśli jesteś głównym architektem oprogramowania dla chirurga plastycznego nosa Dr. No's, możesz zorganizować swoje przestrzenie nazw, takie jak ...
DR Nie
Ordynacyjny
ReadTheirWatchNChargeEm
TellEmNuthin
Chirurgia
ElephantMan
MyEyeLidsRGone
Jest to podobne do organizacji .NET ...
Obiekt
System
Rdzeń
IO
Linq
Dane
Odbc
Sql
Wielopoziomowe przestrzenie nazw uzyskuje się po prostu zagnieżdżając bloki przestrzeni nazw.
Przestrzeń nazw DR Nie
Chirurgia przestrzeni nazw
Przestrzeń nazw MyEyeLidsRGone
„Kod VB
Koniec przestrzeni nazw
Koniec przestrzeni nazw
Koniec przestrzeni nazw
lub
Przestrzeń nazw DR Nie Chirurgia. MyEyeLidsRGone
„Kod VB
Koniec przestrzeni nazw