Obiekt JSON vs singleton, Co może singleton czego nie może obiekt JSON Opcje

[pp-layouts]

Zrobiłem sobie klasę AJAX, będącą zestawem narzędzi i mającą jakieśtam swoje właściwości (do konfiguracji). Utworzyłem ją jako zwykły obiekt, będący zmienną globalną mniej więcej tak:

Kod

var AJAX = {
  property1 : null,
  property2 : null,
  method1 : function() {
    ...
  }
}

Odwołuję się do niej prosto: AJAX.method1(); . Komodo Edit daje prawidłowe podpowiedzi do właściwości i metod.
Co więcej, w środku utworzyłem więcej modułów JSON, tak że mogę odwoływać się do nich per AJAX.module1.method1().

Wszystko pięknie. Prawie dokładny odpowiednik klasy statycznej w PHP. Nawet lepiej, bo to klasa która może zawierać inne klasy. Moduł składający się z modułów. Git.

W takim razie po co używać singletonów? Co one mogą, czego nie może moduł JSON?

Zrobiłem pełną edycję poprzedniego posta, bo nikt chyba nie złapał o co mi w ogóle chodzi.



Ten post edytował pp-layouts 1.12.2009, 00:23:12

[pp-layouts]

Hm, filmów jeszcze nie przejrzałem, bo aktualnie (wiem, że jest niedziela, ale mam deadline z projektem na jutro) pracuję (IMG:style_emoticons/default/smile.gif) Co do singletonów - z tego co piszesz, to ja już nieśmiało wnioskuję, że to chyba żadna, albo prawie żadna różnica, czy sobie zdefiniuję jakąś funkcjonalność w klasie statycznej, czy w kanonicznym singletonie z getInstance, tak czy siak kompilator musi cały kod sparsować, a kwestię inicjowania naszych toolkitów na razie pomijamy (też da się to tak samo ekonomicznie zrobić w jednym i drugim przypadku, moje statyczne klasy mają metodę init() tam gdzie jest potrzebna, oczywiście w pierwszej linii tej metody jest sprawdzenie jednej ze zmiennych statycznych, żeby odpuścić sobie wykonywanie więcej niż raz).

Co do undefined - dzięki, faktycznie, odwołanie do niezadeklarowanej zmiennej operatorem === powoduje wysypanie JS, debugger zwraca błąd i przerywa wykonywanie skryptu. Użycie typeof jest za to nieszkodliwe. Cóż, metoda porównania bezpośredniego będzie szybsza do sprawdzania czy podano parametr funkcji czy nie. Co do szukania zmiennych - tak, teraz rozumiem o co tu chodzi, to bardzo logiczne, stąd nabiera sensu początek jQuery 1.3.2:

[JAVASCRIPT] pobierz, plaintext 
(function() {
var
  // Will speed up references to window, and allows munging its name.
  window = this,
  // Will speed up references to undefined, and allows munging its name.
  undefined,
[JAVASCRIPT] pobierz, plaintext 

Pokombinuję jeszcze z tym jak będę optymalizował swój projekt, na razie ma "tylko" działać (IMG:style_emoticons/default/smile.gif)

Z optymalizacji, których używam standardowo, to większość selektorów jQuery odpalam tylko raz po uruchomieniu kodu, a potem odwołuję się do wyników. Dodatkowo używam funkcji find, która w zasadzie robi to samo co context, tylko "z ręki". Różnica w szybkości działania jest zauważalna gołym okiem. I gdzie się da - odwołania po id. Odwołania do zmiennych opłaca się optymalizować tylko w pętlach, albo w event handlerach, gdzie event jest stosunkowo często odpalany. jQuery siłą rzeczy jest najczęściej mielonym kodem, więc ma największy wpływ na wydajność.