Własnie. O co chodzi w tym calym singletonie? keidy i po co bo uzywac?

prosilbym o jakies linki, jedyne co narazie wiem to to, ze ma się cos on do metod statycznych(static).

Signleton jest wzorcem projektowym (ang. pattern). Na tym forum mozna znalezc opis tego wzorca + duzo przykladow implementacji, wystarczy poszukac.
Btw Wpisz w google 'singleton pattern' i od razu dostaniesz mnostwo linkow (szczegolnie polecam Portland Pattern Repository - bardzo duzy zbior patternow).

a gdzie mozna znales jakis konkretny art o oop w php5, bo w manualu sa komentarze, bo malo opisali oop5, albo uzywanie "interfaces" ? sory ze tak truje

na zendzie masz troche, ale lepiej Eckela poczytaj

No więc tak. Singleton to wzorzec projektowy przydatny, kiedy trzeba utworzyć obiekt, który powinien być dostępny dla różnych, odręnych części aplikacji. W szeczólności jeżeli obiekt ten ma zawierać dużą ilość informacji, to każdorazowe tworzenie jego egzemplarza może okazać się niezwykle mało efektywne. A tutaj mogę Ci pokazać przykład zastosowania singleton'a w praktyce:

http://www.opb.ibplanet.pl/work/dev/bela_666/belacms/ oczywiście autor - bela_666

Albo artykuł po polsku

Zamiast singletona możesz używać z powodzeniem zmiennych globalnych

na początku

[PHP] pobierz, plaintext 
<?php
 
global $MojObiekt;
$MojObiekt = new MojObiekt();
 
?>
[PHP] pobierz, plaintext 

później wszędzie w aplikacji

[PHP] pobierz, plaintext 
<?php
 
global $MojObiekt;
$MojObiekt->zrobCos('!!!');
 
?>
[PHP] pobierz, plaintext 

Zawsze używasz tego samego obiektu, po co komplikować sobie życie jakimiś wzorcami projektowymi

Teraz trochę o wzorcach, nie mówię o tym konkretnym przypadku tylko ogólnie. Wzorce projektowe są to rozwiązania do pewnych problemów, nie znaczy, że są jedynym słusznym rozwiązaniem i że zawsze należy je stosować gdzie tylko się da, to programista jest od tego żeby zdecydować co jest słuszne a co nie, na podstawie własnego doświadczenia, musi myśleć gdy pisze aplikację, należy na to spojrzeć pod kątem problemu, który nasz program ma rozwiązać, prostota rozwiązania, bo jeżeli użycie jakiegoś wzorca nie da nam za dużych korzyści a tylko skomplikuje życie, to nie stosujcie go, jeżeli macie inne lepsze rozwiązanie, które się sprawdzi w waszej aplikacji to je zastosujcie, i nie słuchajcie innych mądrali, którzy wam powiedzą, że jesteście głupi, bo nie użyliście tego czy tamtego wzorca, to oni są głupi bo wszystko chcą na siłę wepchnąć do swojej aplikacji, myślą w imię stosowania wzorców projektowych, w imię, że to musi być "poprawnie" zrobione, a stosowanie wzorców jest jedynym takim słusznym rozwiązaniem! To tak samo jak z programowaniem obiektowym, mamy napisać jakąś prostą aplikację, programista Java, powie, że to musi być zrobione w jedyny słuszny i poprawny sposób, będzie się męczył kilka dni, napisze setki obiektów, tysiące linijek kodu, program będzie zżerał megabajty pamięci etc. Sprytny hacker phpowiec myśli o rozwiązaniu problemu, jeżeli może to shackować za pomocą kilku funkcyjek i strasznie pomieszanego kodu spaghetti to może to być o wiele lepsze i wydajniejsze rozwiązanie, napisane w kilka godzin, co z tego, że jest napisane brzydko, skoro to DZIAŁA! i rozwiązuje nasz problem, co z tego, że jest to źle zrobione, bez zastosowania jedynych i słusznych wzorców projektowych. On to zrobił, to działa, tylko to się liczy. Także moja rada dla wszystkich młodych niedoświadczonych talentów: myślcie, myślcie i jeszcze raz myślcie! Nie pozwólcie by inni myśleli za was

No cóż - dla osób wierzących, że każdy patterns jest dobry, i że warto wykorzystywać wszystkie na raz - polecam uroczy przykład: http://www.phppatterns.com/index.php/artic...leview/103/1/1/

Niestety - to byłoby wszystko, z czym moge się zgodzić z przedmówcą. Bowiem w przypadku programowania w php praktycznie nie ma miejsca na "brzydki" kod. Bo o ile jeszcze kod takowy można stolerować w przypadku bibliotek napisanych w c, które są kompilowane i zapomina się o tym, co jest w środku, to w przypadku kodu php, ten jest poprawiany, modyikowany i dopieszczany na dziesiątki sposobów i możliwości.
Taka natura tego języka. A jeśli jeszcze do jakiegoś projektu chce się zabrać kilka osób, to próba pisania "hackerskiego" staje się prawdziwym wyczynem.
Wtedy właśnie okazuje się, że singeleton nagle staje się znacznie bezpieczniejszy i łatwieszy do skontrolowania, niż zmienna globalna (choćby dlatego, że nie da się go nadpisać) a inne patternsy są przyjmowane wręcz z radością - ponieważ już po jednym rzucie okiem na nazwe klasy można (przynajmniej w teori ) powiedzieć, jak bedzie działać.
I niezależnie od tego, że taki kod również można strasznie skomplikować, i uczynić strasznie zawilym (programistom OOP zdaża się to zresztą bardzo często) to jednak z natury jest bezpieczniejszy i łatwiejszy do modyfikacji (nie koniecznie oznacza to, że jest również łatwiejszy do zrozumienia)

No - ale to tyle gwoli mowy o samym OOP i różnych patternsach.
A wracając do singletona - jeśli ktoś pisze w php5, to uważam, że jest to pierwszy pattern, który powinien poznać, zrozumieć, i zacząć stosować.

Ja nie zaprzeczam tego co napisałeś, możliwe, że w większości sytuacji zastosowanie tego będzie najlepszym rozwiązaniem, ale o tym powinień ktoś zadecydować, a nie na siłę pchać wszystko, o to mi chodzi, staram się tylko uświadomić, że są także inne opcje! I możliwe, że w niektórych sytuacjach będą lepszym rozwiązaniem.

Co do brzydkiego kodu .. mamy po prostu inne definicje tego słowa, ja nie znam się na brzydkim kodzie c/c++, więc jakbym go poznał, pewnie słowo "brzydki kod php" zamieniłbym na "niezbyt ładny kod php"

[PHP] pobierz, plaintext 
<?php
 
class Singleton
{
	private static $zmienna = false; //def. i inicjalizacja...
	public $wlasnosc; //def.
 
	private function __construct(){}
	public static function wezZmienna()
	{
		if (self::$zmienna === false) { 
			//$zmienna nie moze miec wartosci typu int (0)... 
			self::$zmienna = new Singleton;
		}
		return self::$zmienna;
	}
}
 
$a = Singleton::wezZmienna();
$b = Singleton::wezZmienna();
$a->wlasnosc = &#092;"Hello World!\";
echo $b->wlasnosc;
?>
[PHP] pobierz, plaintext 

co my tu mamy ?
#1 nie można utworzyć obiektu poza klasą (poprzez new Singleton) [prywatny konstruktor]
#2 obiekt a i b korzystają z tej samej zmiennej (a w zasadzie z tego samego egzemplarza), dlaczego ?
-przypadek pierwszy (utworzenie indywiduum a)
$zmienna statyczna ma wartość false -> instrukcja sterująca korzystając z powyższej zmiennej (false) tworzy obiekt statyczny wewnątrz funkcji -> $zmienna (obiekt) jest zwracana
-przypadek drugi (utworzenie obiektu
$zmienna statyczna ma wartość false -> instrukcja sterująca umieszczona wewnątrz funkcji nie korzysta ze zmiennej utworzonej na początku klasy (o wartości false) tylko z wcześniej utworzonego obiektu (kopia zmiennej lokalnej) w tej funkcji -> $zmienna jest zwracana (defacto została stworzona wcześniej)

#3 $a->wlasnosc = "Hello World!"; -> modyfikuje globalny (pojedyńczy) obiekt wygenerowany przez klasę

#4 funkcja wezZmienna() korzysta z wzorca Factory


powyższy post jest efektem głębokich przemyśleń autora nad wzorcem typu Singleton i jest prawdopodobnie opisem działania tegoż wzorca, the end...