Witam. Które podejscie jest poprawne (wydajniejsze i bardziej uznane)?

konstruktory?

[PHP] pobierz, plaintext 
function HidingTextOnInput(inputId, inputCaptionToShow) {
 
	this.inputId = inputId;
	this.inputCaptionToShow = inputCaptionToShow;
	this.controlWasClicked = false;
 
	this.getInputControl= function ()
	{
		return $("#" + this.inputId);
	}
 
	this.setControlInitialText=function()
	{
		this.getInputControl().val(this.inputCaptionToShow);
		this.controlWasClicked=false;
	}
 
	this.onBlur = function ()
	{
		if (this.getInputControl().val() == "") 
		{
			this.setControlInitialText();
		}
	}
}
[PHP] pobierz, plaintext 

czy prototypy?

[PHP] pobierz, plaintext 
function newObject()
{
}
 
newObject.prototype.doCostam = function ()
{
}
 
newObject.prototype.doWow = function() 
{
}
 
newObject.prototype.constructor = newObject()
{
}
[PHP] pobierz, plaintext 

skladniowo podobaja mi sie bardziej konstruktory. Z prototypow nie korzystalem nigdy jakos odpychają mnie, podoba mi sie to ze mam w konstruktorze zamkniete w jednej funkcji cos na ksztalt klasy (cale bebechy w konstruktorze).

Slyszalem ze prototypy sa sporo wydajniejsze stad moje zainteresowanie nimi.

Przy prototypach tracisz pełną wydajność (przeszukiwanie łańcucha prototypów) - przy wrzucaniu metod w konstruktorze o ile dobrze kojarzę tracisz pamięć (ale to trzeba sprawdzić).
Podejrzewam, że ten drugi argument może (podkreślam "może") być zbity z tego względu, że to co teraz robią z silnikami JS to magia, magia i jeszcze raz magia.
W większości przypadków mój argument jest jednak słuszny ponieważ każda funkcja musi pamiętać swój własny kontekst utworzenia i zmiennych w nim istniejących.

http://www.blog.highub.com/javascript/java...r-vs-prototype/ -> Potwierdza, że tworzenie metod w konstruktorze = więcej zużytej pamięci.

A ja tam nigdy nie patrzyłem na pamięc. Ja używam prototype bo dla mi osobiście bardziej to pasuje, kod dla mnie wydaje się czytelniejszy.
Pozatym używając prototype możemy rozszerzać daną klasę w dowolnym miejscu. Ma to zastosowanie w pewnych sytuacjach.

W konstruktorze również.

[JAVASCRIPT] pobierz, plaintext 
function C1 () {
    this.metoda1 = function() {
        alert('cos');
    }
}
 
function C2 () {
    C1.call(this);
    this.metoda2 = function() {
        alert('cos2');
    }
}
 
var o = new C2;
o.metoda1();
[JAVASCRIPT] pobierz, plaintext 

Pamięć jest ważna. GC dla JS jest nieubłagane.

Moim skromnym zdaniem prototypy są częściej wykorzystywane, a co do wydajności to spada ale nie w każdym wypadku:


Źródło: http://bonsaiden.github.com/JavaScript-Garden/pl/

Poczytaj w powyższym linku, bardzo fajnie wszytko opisane.

Poza tym przypominam, że w podejściu prototypowym nie da się uzyskać właściwości prywatnych.

A jak w konstruktorze stworzysz właśność prywatną?

http://javascript.crockford.com/private.html

Jest to pseudo private moim zdaniem. Jakby było pełne private danego obiektu to by było: this. secret. A oni używają poprostu secret, czyli defacto korzystają z zasięgu zmiennych.
Czyli tak, constructor pozwala na definiowanie pseudo prywatnych właściwości.

Nie, w ten sposób tworzysz właściwość publiczną. To, że tak się dzieje w innych językach wcale nie oznacza, że identycznie ma się dziać w js.
To co czytasz wyżej to pełna realizacja właściwości prywatnej. Jest przypisana do jednego konkretnego obiektu i niedostępna dla innych.
Gdzie tu jest miejsce na "pseudo"?

wiem

Jak dla mnie jest to wynikiem zasięgu zmiennych stąd nazwa pseudo. Ogólnie obiektówka w js dla to wielkie "pseudo". I jeśli można z zasięgu zmiennej zrobić właściwość prywatną to super i hiper. Nie mam nic do tego.
Tak samo jak nie mam nic do pseudo dziedziczenia w js

Dlaczego znów "pseudo dziedziczenie" ?

Ponieważ zarówno by osiągnąć "prywatność" jaki i dziedziczenie trzeba kombinować Fakt, są to opisane metody, ale moim zdaniem jest to kombinowanie. Używam tych metod i jest mi z tym dobrze. Nie zmienia to faktu, iż uważam to nadal za "pseudo" i nie widzę powodu by dalej się o to kłócić

Tak na szybkiego zanim napiszę to coś wytłumaczę
Zawsze jak widzę, że Nospor coś napisał na forum to czytam post, lubię jego posty, a mój syn zawsze patrzy na kubusia puchatka
ale nie mogę się zgodzić co do pseudo obiektowości javascriptu, pseudo jest ale enkapsulacja, sama obiektowość w javascript moim zdaniem jest pełna enkapsulacja to tylko jeden niewielki składnik obiektowości.
Równie dobrze można powiedzieć, że w C++ jest pseudo obiektowość bo nie ma tak pięknie obiektowej składni jak java i można pisać strukturki

Taka dygresja ale to chyba za szeroki temat na ten post

rękawica podniesiona.....
A więc zajmijmy się pseudo na przykładzie "właściwości prywatnych".


Mamy tutaj funkcję test a w niej zmienną lokalną o nazwie secret.
Wystarczy, że zrobimy new

And magic..... zmienna lokalną zmienia się we "właściwość prywatną"...
No dobra. Skoro mamy już tę wspaniałą "właściwość prywatną" znaczy, że jest ona dostępna dla wszystkich metod danej klasy. No to jedziem dalej z koksem:

Kto mi teraz wyjaśni czemu moja "właśćiwość prywatna" nie zadziałała? Pewnie powiecie, że przecież nie trzymałem się przepisu i nie tworzyłem tego wszystkiego w konstruktorze. Tak, to prawda. Nie trzymałem się przepisu. ALe gdyby to nie było pseudo to by działało jak ma działać, dla każdej metody klasy test niezależnie jak ją tworzyłem.

Wniosek: to jest pseudo.
A "właściwości prywatne" udało się osiągnąć dzięki efektowi ubocznemu zasięgu zmiennych. I żeby to stosować to trzeba się trzymać ściśle określonego schematu

Ale ja nie twierdzę, że w js nie da się pisać obiektowo. Da się. I sam tak często piszę przy dużych projektach. Ale znam ograniczenia js w tej materii. I wiem, że niektóre rzeczy są pseudo, robione na około przy wykorzystaniu rożnych zachowań js.

Tak, są pewne zasady, ale w innych językach też istnieją zasady nie do złamania, np. konstruktor zawsze musi być publiczny
Ale całkowicie się z tobą zgadzam, z tym że tak jak napisałem - javascript ma problemy z enkapsulacją, na którą po prostu są pewne sposoby, jak napisałeś, ale dzięki pseudo enkapsulacji sama obiektowość javascript jest w pełni obiektowa
Ale na prawdę, tutaj będzie zdań tyle co ludzi bo z jednej strony nie da się w pełni wykorzystać obiektowości bez enkapsulacji
Ja rękawic nie podejmę, można się podknąć na ringu o każą nierówność

Zacznijmy od tego, że do co teraz robisz to rozszerzasz obiekt o dodatkowe metody w czasie wykonywania programu (runtime).
W dodatku wrzucasz metodą do innej "warstwy" obiektu (czytaj prototyp) co w przypadku PHP mogłoby oznaczać np coś takiego.

[PHP] pobierz, plaintext 
class test {
	private $_variable = 'test';
	private $_callbacks = array();
 
	public function addCallback($function, Closure $closure) {
		$this->_callbacks[$function] = $closure;
	}
 
	public function __call($method, $args) {
		return call_user_func_array($this->_callbacks[$method], $args);
	}
}
 
$o = new test();
$o->addCallback('testowa', function() use ($o){
	return $o->_variable;
});
 
echo $o->testowa();
[PHP] pobierz, plaintext 

Więc co... w php też mamy pseudo zmienne prywatne, które uzyskujemy "tylko" dlatego, że zdefiniowaliśmy je bezpośrednio w klamrach klasy?

Pamiętaj, że JS to prototypowy język funkcyjny więc rządzi się zasadami tego języka.
Co prawda odmiennymi niż w innych językach ale to wcale nie znaczy, że są złe.

Nospor - próbujesz narzucić przyzwyczajenia z innych języków do JS. Każdy język się różni dlatego jest i tak wiele. Każdy ma swoje przeznaczenie, swoich fanów, swoich wrogów.
Przeczytaj bardzo dobrą książkę http://pragprog.com/book/btlang/seven-lang...-in-seven-weeks , która otwiera umysł na "zmiany", inne spojrzenie a nie konserwatyzm.

Dostęp do zmiennej prywatnej owszem ,ale już jej modyfikowanie już chyba nie.

Czy to zadziała?
Ja u siebie często używam w singeltonie prywatnych zmiennych do ustawiania zmiennych środowiskowych.

@wookieb to ty przykładem z php próbujesz coś z js przenieść na php. I to nie udolnie
W moim kodzie js nie operowałem na obiekcie tylko prototype używałem na definicji funkcji/klasy. Ty w php dodajesz metody do obiektu

Źle mnie zrozumiałeś. Ja jestem fanem js. Odkąd go poznałem lepiej to się w nim zakochałem. Ale mam swoje zdanie i uważam, że parę rzeczy zrobili naokoło. Bo kiedyś o tym nie pomyśleli, ale się okazało, że nagle by się przydało. I wymyślają przepisy jak zrobić daną rzecz przy wykorzystaniu już istniejących. I takim właśnie przykładem są "właściwośći prywatne". Koniec kropka, nie przekonasz mnie w żaden sposób a już tym bardziej nie tekstem że jestem konserwatywny i nie mogę spojrzeć szerzej.... Co ma piernik do wiatraka? Patrze szerzej, rozumiem, że w js robi się inaczej pewne rzeczy, ale mam chyba prawo powiedzieć, że jest to pseudo. Bo jest Przykład z poprzedniego posta bardzo dobrze to pokazuje.

@down: ok

Niktoś - po raz kolejny bezsensownie nabijasz posty. To co mówisz o singletonie ma jakikolwiek związek z tematem?
Nie - więc przystopuj troszkę ze Swoimi komentarzami.

@UP - skończmy tą dyskusję na tym etapie.

Dyskusja dotyczyła js,potem kłótnia o zasięg zmiennych prywatnych.Co do tego ma singelton?Już pokazuje:

[CSHARP] pobierz, plaintext 
public class Moja_Klasa
    {  
private string pupa;
public Moja_Klasa(){}
 
   public string blada
        {
            get { return pupa; }
            set { pupa = value; }
        }   
 
}
[CSHARP] pobierz, plaintext 

Zmienna prywatna to nie zmienna publiczna,a dostęp do niej i modyfikacja jest znacznie utrudniona.Jak widzisz dostęp do zmiennej prywatnej tylko za pomocą akcesorów-czy to oznacza pseudo prywatność?.Jeśli chodzi o js według mnie to wygląda w ten sposób-JS nie ma zmiennych globalnych,prywatnych,ale można to emulować tak jak to Nospor pokazał,dlatego według mnie można to spokojnie nazwać pseudo.
Wookieb, jak to nabicie posta to powiedz-to pousuwam swoje wszystkie 650 postów.

Akcesory to akcesory. Normalny mechanizm.
Ale jak ma się do tego singleton to i ja nadal nie wiem

Żywcem ze strony ms.

[CSHARP] pobierz, plaintext 
public sealed class Singleton
{
   private static readonly Singleton instance = new Singleton();
 
   private Singleton(){}
 
   public static Singleton Instance
   {
      get 
      {
         return instance; 
      }
   }
}
[CSHARP] pobierz, plaintext 

Do zwracania instancji także użyty został akcesor-zwracana jest instancja.Nie widzisz podobieństwa?

Równie dobrze można było użyć metody getInstance().
Równie dobrze można było użyć akcesora.
Super, ale jak to się ma do tematu? Fakt, temat ogólnie zboczył z toru na inny, ale twoja wstawka to zboczenie z toru na polną drogę, z torami nie mającą nic wspólnego

@down
Dziękujemy za wyjaśnienie. Od lat się zastanawiałem po co stosować public albo private a tu patrz... jest różnica.....

No zboczył z toru na temat zakresu zmiennych prywatnych.U mnie to wszystko fajnie widać właśnie na takich klasach.I jest różnica między private a public.Jeśli chodzi o js tak jak wyżej.
Ja ten temat kontynuować nie bedę,bo chyba nie o to chodziło autorowi.

Wiem Niktoś, wyglądam jak prześladowca, aż zacząłem się z tego teraz śmiać pod nosem ale... temat czy rozpoczęty, czy w trakcie dyskusji nie ma praktycznie nic wspólnego z twoim postem (znowu ).
Chodzi o obiektowość samego javascriptu, a enkapsulacja to tylko jeden z argumentów dyskusji

Nawet po avatarze to widać

Ja się przyzwyczaiłem, że prototype używam tylko kiedy potrzebuje rozrzeżyć funkcjonalność konstruktora do którego nie mam bezpośredniego dostępu:

[PHP] pobierz, plaintext 
window.HTMLElement.prototype.$$ = function(){
	return this.querySelectorAll.apply(this,arguments);
}
[PHP] pobierz, plaintext 

W innym wypadku konstruktor zawsze mozna zmienić więc prototypów nie używam bo jest to nieprzejrzyste.