Pakiety i przestrzenie nazw

Definiowanie przestrzeni nazw

Każda przestrzeń nazw zawiera jedną wartość, tzw. identyfikator URI (ang. Uniform Resource Identifier), który jest czasami nazywany nazwą przestrzeni nazw . Identyfikator URI zapewnia unikalność definicji przestrzeni nazw.

Przestrzeń nazw można utworzyć, deklarując jej definicję na jeden z dwóch sposobów. Przestrzeń nazw można zdefiniować, podając jawnie identyfikator URI (tak jak przy definiowaniu przestrzeni nazw XML), lub nie podając identyfikatora URI. Poniższy przykład ilustruje definiowanie przestrzeni nazw przy użyciu identyfikatora URI:

namespace flash_proxy = "http://www.adobe.com/flash/proxy";

URI jest ciągiem znaków jednoznacznie identyfikującym daną przestrzeń nazw. W wypadku pominięcia identyfikatora URI, tak jak w poniższym przykładzie, kompilator tworzy w jego miejsce unikalny wewnętrzny ciąg identyfikacyjny. Programista nie ma dostępu do tego wewnętrznego ciągu znaków.

namespace flash_proxy;

Raz zdefiniowanej przestrzeni nazw — z użyciem lub bez użycia identyfikatora URI — nie można ponownie zdefiniować w tym samym zasięgu. Próba zdefiniowania przestrzeni nazw, która została już wcześniej zdefiniowana w tym samym zasięgu, spowoduje błąd kompilatora.

Przestrzeń nazw zdefiniowana w pakiecie lub klasie może być niewidoczna dla kodu poza tym pakietem lub klasą, o ile nie zostanie użyty odpowiedni specyfikator dostępu. Poniższy przykładowy kod przedstawia definicję przestrzeni nazw flash_proxy wewnątrz pakietu flash.utils. W przykładzie tym brak specyfikatora dostępu oznacza, że klasa flash_proxy będzie widoczna tylko dla kodu w pakiecie flash.utils i że będzie niewidoczna dla kodu poza pakietem:

package flash.utils 
{ 
    namespace flash_proxy; 
}

W poniższym kodzie użyto atrybutu public , aby przestrzeń nazw flash_proxy była widoczna dla kodu poza pakietem:

package flash.utils 
{ 
    public namespace flash_proxy; 
}

Stosowanie przestrzeni nazw

Zastosowanie przestrzeni nazw polega na umieszczeniu definicji w tej przestrzeni. W przestrzeniach nazw można umieszczać funkcje, zmienne i stałe (nie można umieścić klasy w niestandardowej przestrzeni nazw).

Rozważmy na przykład funkcję zadeklarowaną przy użyciu specyfikatora dostępu (przestrzeni nazw) public . Użycie atrybutu public w definicji funkcji powoduje umieszczenie tej funkcji w publicznej przestrzeni nazw, przez co staje się ona dostępna dla całego kodu. Po zdefiniowaniu niestandardowej przestrzeni nazw można używać jej w taki sam sposób, jak atrybutu public , co spowoduje, że definicje będą dostępne dla kodu, który może odwoływać się do niestandardowej przestrzeni nazw. Na przykład, jeśli zdefiniujemy przestrzeń nazw example1 , możemy dodać metodę myFunction() z atrybutem example1 , co ilustruje poniższy przykład:

namespace example1; 
class someClass 
{ 
    example1 myFunction() {} 
}

Zadeklarowanie metody myFunction() przy użyciu przestrzeni nazw example1 jako atrybutu oznacza, że metoda ta będzie należała do przestrzeni nazw example1 .

Stosując przestrzenie nazw, należy pamiętać o następujących uwarunkowaniach:

• Do każdej deklaracji można zastosować tylko jedną przestrzeń nazw.

• Nie ma możliwości zastosowania atrybutu przestrzeni nazw do więcej niż jednej definicji naraz. Innymi słowy, jeśli chcemy zastosować własną przestrzeń nazw do dziesięciu różnych funkcji, należy dodać tę przestrzeń nazw jako atrybut do definicji każdej z tych funkcji.

• Zastosowanie przestrzeni nazw wyklucza jednoczesne zastosowanie specyfikatora dostępu. Innymi słowy, nie można zadeklarować funkcji lub właściwości z atrybutem public , private , protected, lub internal i dodatkowo zastosować własnej przestrzeni nazw.

Odwołania do przestrzeni nazw

Nie jest konieczne jawne odwoływanie się do przestrzeni nazw, gdy używamy metod lub właściwości zadeklarowanych za pomocą dowolnego ze specyfikatorów dostępu, np. public , private , protected lub internal . Wynika to z faktu, że dostęp do przestrzeni nazw identyfikowanych przez te specyfikatory odbywa się na podstawie kontekstu. Na przykład definicje umieszczone w przestrzeni nazw private będą automatycznie dostępne dla kodu w tej samej klasie. Jednak w przypadku przestrzeni nazw zdefiniowanych przez użytkownika dostępność nie jest zależna od kontekstu. Aby użyć metody lub właściwości umieszczonej w niestandardowej przestrzeni nazw, należy odwołać się do tej przestrzeni.

Do przestrzeni nazw można się odwołać za pomocą dyrektywy use namespace lub kwalifikując nazwę przestrzeni nazw za pomocą operatora :: . Odwołanie za pomocą dyrektywy use namespace „otwiera” przestrzeń nazw, tak że zaczyna ona obowiązywać dla wszystkich identyfikatorów niekwalifikowanych. Na przykład, jeśli została zdefiniowana przestrzeń nazw example1 , można uzyskiwać dostęp do nazw w tej przestrzeni po wydaniu dyrektywy use namespace example1 :

use namespace example1; 
myFunction();

Możliwe jest otwarcie więcej niż jednej przestrzeni nazw w danej chwili. Przestrzeń nazw otwarta za pomocą dyrektywy use namespace pozostaje otwarta do końca bloku kodu zawierającego tę dyrektywę. Nie ma możliwości jawnego zamknięcia przestrzeni nazw.

Jednak otwarcie więcej niż jednej przestrzeni nazw naraz zwiększa prawdopodobieństwo konfliktów nazw. Aby uniknąć otwierania przestrzeni nazw za pomocą dyrektywy use namespace , można kwalifikować nazwy metod lub właściwości za pomocą nazwy przestrzeni nazw i operatora ::. Poniższy przykładowy kod ilustruje kwalifikowanie nazwy myFunction() przestrzenią nazw example1 :

example1::myFunction();

Korzystanie z przestrzeni nazw

W klasie flash.utils.Proxy, która jest częścią języka ActionScript 3.0, można znaleźć rzeczywiste przestrzenie nazw użyte w celu zapobieżenia konfliktom nazw. Klasa Proxy, która zastępuje właściwość Object.__resolve występującą w języku ActionScript 2.0, umożliwia przechwytywanie odwołań do niezdefiniowanych właściwości lub metod zanim takie odwołanie spowoduje błąd. Wszystkie metody klasy Proxy rezydują w przestrzeni nazw flash_proxy , co zapobiega konfliktom nazw.

Aby lepiej zrozumieć sposób wykorzystania przestrzeni nazw flash_proxy , należy zapoznać się z zasadami korzystania z klasy Proxy. Funkcjonalność klasy Proxy jest dostępna tylko dla klas, które z niej dziedziczą. Innymi słowy, aby można było używać metod klasy Proxy w obiekcie, klasa tego obiektu musi rozszerzać klasę Proxy. Na przykład, jeśli chcemy przechwytywać próby wywołania niezdefiniowanej metody, należałoby rozszerzyć klasę Proxy, a następnie przesłonić metodę callProperty() tej klasy.

Jak pamiętamy, implementacja przestrzeni nazw przebiega zazwyczaj w trzech krokach i polega na zdefiniowaniu, zastosowaniu przestrzeni nazw i odwołaniu się do niej. Ponieważ jednak metody klasy Proxy nigdy nie są wywoływane jawnie, przestrzeń nazw flash_proxy jest zdefiniowana i zastosowana, ale kod nigdy się do niej nie odwołuje. Język ActionScript 3.0 definiuje przestrzeń nazw flash_proxy i stosuje ją w klasie Proxy. Kod użytkownika musi stosować przestrzeń nazw flash_proxy tylko do klas rozszerzających klasę Proxy.

Przestrzeń nazw flash_proxy jest zdefiniowana w pakiecie flash.utils w sposób podobny do przedstawionego poniżej:

package flash.utils 
{ 
    public namespace flash_proxy; 
}

Przestrzeń nazw jest stosowana do metod klasy Proxy tak, jak ilustruje to poniższy fragment tej klasy:

public class Proxy 
{ 
    flash_proxy function callProperty(name:*, ... rest):* 
    flash_proxy function deleteProperty(name:*):Boolean 
    ... 
}

Tak jak przedstawiono to w poniższym przykładzie, należy najpierw zaimportować zarówno klasę Proxy, jak i przestrzeń nazw flash_proxy . Następnie należy zadeklarować własną klasę tak, aby rozszerzała ona klasę Proxy (należy także dodać atrybut dynamic , jeśli kompilacja odbywa się w trybie ścisłym). Przesłaniając metodę callProperty() , należy użyć przestrzeni nazw flash_proxy .

package 
{ 
    import flash.utils.Proxy; 
    import flash.utils.flash_proxy; 
 
    dynamic class MyProxy extends Proxy 
    { 
        flash_proxy override function callProperty(name:*, ...rest):* 
        { 
            trace("method call intercepted: " + name); 
        } 
    } 
}

W wypadku utworzenia instancji klasy MyProxy i wywołania metody niezdefiniowanej, jak metoda testing() wywoływana w poniższym przykładzie, obiekt Proxy przechwyci wywołanie metody i wykona instrukcje wewnątrz przesłoniętej metody callProperty() (w tym przypadku jest to prosta instrukcja trace() ).

var mySample:MyProxy = new MyProxy(); 
mySample.testing(); // method call intercepted: testing

Umieszczenie metod klasy Proxy wewnątrz przestrzeni nazw flash_proxy przynosi dwie korzyści. Po pierwsze, użycie odrębnej przestrzeni nazw upraszcza interfejs publiczny każdej klasy, która rozszerza klasę Proxy. (Klasa Proxy zawiera kilkanaście metod, które można przesłaniać, a które nie są przeznaczone do bezpośredniego wywoływania. Umieszczenie ich wszystkich w przestrzeni nazw public byłoby mylące). Po drugie użycie przestrzeni nazwa flash_proxy pozwala uniknąć konfliktów nazw w sytuacji, gdy podklasa Proxy zawiera metody instancji o nazwach identycznych z nazwami metod klasy Proxy. Załóżmy, że jednej z naszych metod chcemy nadać nazwę callProperty() . Poniższy kod jest formalnie poprawny, ponieważ nasza wersja metody callProperty() znajduje się w innej przestrzeni nazw:

dynamic class MyProxy extends Proxy 
{ 
    public function callProperty() {} 
    flash_proxy override function callProperty(name:*, ...rest):* 
    { 
        trace("method call intercepted: " + name); 
    } 
}

Przestrzenie nazw są także pomocne, gdy chcemy zapewnić dostęp do metod lub właściwości w sposób niemożliwy do zrealizowania za pomocą żadnego z czterech specyfikatorów dostępu ( public , private , internal i protected ). Załóżmy na przykład, że mamy kilka metod pomocniczych rozproszonych po kilku pakietach. Chcemy, aby te metody były dostępne dla wszystkich naszych pakietów, ale nie chcemy deklarować ich jako publicznych. Aby uzyskać pożądany skutek, utworzymy przestrzeń nazw i użyjemy jej jako własnego specjalnego specyfikatora dostępu.

W poniższym przykładzie zastosowano przestrzeń nazw zdefiniowaną przez użytkownika w celu zgrupowania dwóch funkcji rezydujących w różnych pakietach. Zgrupowanie ich w jednej przestrzeni nazw powoduje, że mogą być uwidocznione dla klasy lub pakietu za pomocą jednej instrukcji use namespace .

W tym przykładzie omawianą technikę zademonstrowano przy wykorzystaniu czterech plików. Wszystkie te pliki muszą znajdować się w ścieżce klas. Pierwszy plik, myInternal.as, definiuje przestrzeń nazw myInternal . Ponieważ plik ten znajduje się w pakiecie o nazwie example, należy umieścić go w folderze o nazwie example. Przestrzeń nazw jest oznaczona jako public , a więc można ją importować do innych pakietów.

// myInternal.as in folder example 
package example 
{ 
    public namespace myInternal = "http://www.adobe.com/2006/actionscript/examples"; 
}

Drugi i trzeci plik, Utility.as oraz Helper.as, definiują klasy zawierające metody, które powinny być dostępne w innych pakietach. Klasa Utility znajduje się w pakiecie example.alpha, co oznacza, że plik należy umieścić w folderze o nazwie alpha będącym podfolderem folderu example. Klasa Helper znajduje się w pakiecie example.beta, co oznacza, że plik należy umieścić w folderze o nazwie beta będącym podfolderem folderu example. Oba pakiety, example.alpha i example.beta, muszą zaimportować przestrzeń nazw, zanim zostanie ona użyta.

// Utility.as in the example/alpha folder 
package example.alpha 
{ 
    import example.myInternal; 
     
    public class Utility 
    { 
        private static var _taskCounter:int = 0; 
     
        public static function someTask() 
        { 
            _taskCounter++; 
        } 
         
        myInternal static function get taskCounter():int 
        { 
            return _taskCounter; 
        } 
    } 
} 
 
// Helper.as in the example/beta folder 
package example.beta 
{ 
    import example.myInternal; 
     
    public class Helper 
    { 
        private static var _timeStamp:Date; 
         
        public static function someTask() 
        { 
            _timeStamp = new Date(); 
        } 
         
        myInternal static function get lastCalled():Date 
        { 
            return _timeStamp; 
        } 
    } 
}

Czwarty plik, NamespaceUseCase.as, to główna klasa aplikacji, i należy go umieścić na tym samym poziomie, co folder example. W programie Flash Professional byłaby to klasa dokumentu dla pliku FLA. Klasa NamespaceUseCase również importuje przestrzeń nazw myInternal i używa jej do wywołania dwóch metod statycznych rezydujących w innych pakietach. W przykładzie zastosowano metody statyczne wyłącznie w celu uproszczenia kodu. W przestrzeni nazw myInternal można umieszczać zarówno metody statyczne, jak i metody instancji.

// NamespaceUseCase.as 
package 
{ 
    import flash.display.MovieClip; 
    import example.myInternal; // import namespace 
    import example.alpha.Utility;// import Utility class 
    import example.beta.Helper;// import Helper class 
     
    public class NamespaceUseCase extends MovieClip 
    { 
        public function NamespaceUseCase() 
        { 
            use namespace myInternal; 
             
            Utility.someTask(); 
            Utility.someTask(); 
            trace(Utility.taskCounter); // 2 
             
            Helper.someTask(); 
            trace(Helper.lastCalled); // [time someTask() was last called] 
        } 
    } 
}