Hej,

Zastanawiam się czy wykorzystanie metody "getInstance" w metodach statycznych, w klasie która jest Singletonem jest poprawne.

[PHP] pobierz, plaintext 
class Singleton{
  private static $instance;
  private $varOne = 0;
  private function __construct(){}
 
  static function getInstance(){
    if(self::instance==null){
      self::instance=new Singleton();
    }
    return self::instance;
  }
 
  static function doSomething(){
    echo self::getInstance()->varOne;
  }
}
[PHP] pobierz, plaintext 

Zamiast pisać:

[PHP] pobierz, plaintext 
Singleton::getInstance()->doSomething();
[PHP] pobierz, plaintext 

Mogę używać:

[PHP] pobierz, plaintext 
Singleton::doSomething();
[PHP] pobierz, plaintext 

Dlaczego tak? Chciałbym skrócić zapis najczęściej używanych metod, ale mam spore obawy co do tego czy taki zapis nie jest niezgodny z wzorcem.

No a Co poza zwróceniem obiektu robi "getInstance" ?

Przeczytaj sobie dokładnie (pełno tego w internecie) czym jest singleton w PHP.
Twoje przykładowe getInstance jest potrzebne, jeśli to faktycznie ma być Singleton i ma być stworzona tylko jedna instancja danej klasy. Dobrym przykładem jest np. singleton połączenia z bazą danych. To czy potrzebny Ci singleton, już zależy od Ciebie i aplikacji

Kłóciłbym się z tym bardzo...

Dlaczego? Może rozwiniesz wypowiedź? Ja uważam, że jest to dobry przykład, aby zrozumieć po części, do czego służy singleton. Wyraźnie widać, że połączenie tworzy się wtedy tylko i wyłącznie raz, a wszelkie kolejne odwołania, korzystają już z otwartego, czyż nie o to chodzi w singletonie?

Nie raz są potrzebne dwa połączenia z bazą danych, np. w testach jednostkowych. Nie powinno się używać singletonów, gdyż tworzą one statyczne i głębokie zależności, jeśli kiedyś zajdzie potrzeba przetestowania kodu korzystającego z singletonu, bądź z niego zrezygnowania, to możesz mieć problem. Singleton wg mnie w php ma jedynie dydaktyczną wartość, gdyż najłatwiej na jego przykładzie zrozumieć podstawową ideę wzorców projektowych.

Peter, a ja napisałem gdzieś o tym, że trzeba stosować takie singletony zawsze? Czy w ogóle padł temat o ich stosowaniu? Przeczytaj dokładnie co napisałem, chodziło mi o przykład, przez który można zrozumieć zasadę pisania singletonu. W wielu aplikacjach wymagane jest jedno połączenie - w takich przypadkach, klasa singletonu z połączeniem bazy jest dobrym przykładem, aby przyswoić sobie, do czego i dlaczego tak jest. Przecież wiadomo, że każda aplikacja może wymagać innych rzeczy, jednej wystarczy jedno połączenie, jedna baza, a w innej 20 serwerów i 300 połączeń

Dokładnie chodziło mi o to o czym wspomniał @-=Peter=-.
Nie ważne, że w 99% aplikacji łączysz się z jedną bazą, chodzi o to, że klasa DataBase nie jest Singletonem bo to nie jest byt którego może być albo wcale albo sztuk jeden.

Poza tym zawsze powinno się zostawiać furtkę na łatwą rozbudowę jeśli nie wymaga to wielkich nakładów pracy. Debilny przykład - dodania do tabelki pola insertDate z ustawionym current_time, przypuśćmy, że w momencie pisania nie mam planów żeby wykorzystać to pole, ale za 2 lata będę chciał napisać feature, żeby oznaczać użytkowników po miesiącu rejestracji. Jeśli takiego pola nie stworzyłem na początku to tych danych już nie zdobędę ale pomyślałem i utworzyłem sobie takie pole i mogę to wykonać.

Przykład totalnie nie adekwatny ale pokazuje to co chciałem - każdy powinien myśleć jak w przyszłości można rozbudować aplikacje i tworzyć sobie od razu takie możliwości jeśli nie kosztuje go to za dużo.

Więc na to, zacytuje sam siebie z postu wyżej
"Peter, a ja napisałem gdzieś o tym, że trzeba stosować takie singletony zawsze? Czy w ogóle padł temat o ich stosowaniu?"

Nie uważnie przeczytałeś mój post. Napisałem, że NIGDY nie powinno się nadawać sigletona czemuś coś ideowo nie jest singletonem.

Nie ma takiej rzeczy, która nawet w idei może być singletonem.

Dispacher? Klasa systemu szablonów? ;>

Dispatcher czego?
System szablonów nie musi być. Większa ilość mniejszych lepiej spełnia swoje zadanie.
Powtarzam, że nie ma żadnej potrzeby tworzenia jakichkolwiek singletonów.

Wszystko zależy od kontekstu użycia. Na 100 przypadków pojawi się jeden, w którym singleton za jednym zamachem rozwiąże kilka problemów specyficznych dla danego projektu. Mimo wszystko równie dobrze można iść na łatwiznę i próbować używać "global" - zaoszczędzi dużo czasu (przynajmniej tak się będzie wydawało w momencie pisania), ale chyba każdy się zgodzi, że ma nieporównywalnie więcej wad niż zalet. A przecież singleton to takie ładniejsze opakowanie dla zmiennej globalnej. Nie bez powodu choćby w Javie praktykuje się stosowanie fabryk lub dependency injection, zamiast singletonów właśnie.
Osobiście nie neguję całkowicie używania singletonów - sam je czasem stosuję w PHP, np. do obsługi logowania błędów. Jednak, jak wspomniałem na początku, wszystko zależy od kontekstu.