PDO Singleton, Proszę o ocenę |
PDO Singleton, Proszę o ocenę |
16.04.2013, 19:18:47
Post
#1
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Witam.
Chciałbym się dowiedzieć czy idę dobrą drogą Posiadam dwie klasy, które są odpowiedzialne za nawiązywanie łączności z bazą danych. Klasa _DSN - przygotowuję dane potrzebne konstruktorowi PDO, dane te są zapisane w pliku tekstowym. Druga klasa to _PDOConnect(Singleton), odbiera i nawiązuje połączenie z bazą. Klasy są surowe jeżeli chodzi o sprawdzanie błędów itp. jest to świadome.
|
|
|
16.04.2013, 21:00:25
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) |
1. Jeśli ma to być singleton brakuje prywatnej/chronionej metody __clone
2. Przemyślałbym obsługę wielu baz, bo nawet jeśli tego nie przewidujemy to może taka potrzeba się pojawić. I pytanie, czy musi to być singleton bo przecież nie piszemy skryptu, gdzie w każdym pliku na samym początku DB::getInstance() 3. Współpracę klas oceniam fatalnie - poczytaj o wzorcach współpracy klas, na początek dependency injection, "wstrzykiwanie zależności" - tak to chyba po polsku się nazywa 4. Podobnie klasę _DSN - zobacz, jak tego używasz, najpierw tworzysz obiekt by wywołać konstruktor a potem dobierasz się do pól statycznych? Podstawą są gettery i settery a nie kombinowanie metodami statycznymi czy magicznymi. A jeśli już to powinieneś pobrać sobie ten cfg jedną metodą statyczną gdzie przekazujesz ten plik jako parametr, bez konieczności tworzenia obiektu. |
|
|
16.04.2013, 21:29:22
Post
#3
|
|
Grupa: Zarejestrowani Postów: 1 168 Pomógł: 126 Dołączył: 5.02.2010 Skąd: Świdnica Ostrzeżenie: (0%) |
Możesz coś więcej powiedzieć, gdzie tutaj byś zastosował DI?
|
|
|
16.04.2013, 21:54:12
Post
#4
|
|
Grupa: Zarejestrowani Postów: 195 Pomógł: 14 Dołączył: 12.01.2006 Skąd: Gotham City Ostrzeżenie: (0%) |
W konstruktorze _PDOConnect masz nas stałe
powinienes _DSN przesłać w argumencie konstruktora
i już masz wstrzyknięta zależność Singelton to zły pomysł, obsługa jednego połączenia też. Pula połączeń jeśli takowe już istnieje biore z puli. To też zły pomysł. Zmienne prywatne, gety ,sety tak jak pisze ten alkocholik nademna. Ten post edytował emp 16.04.2013, 22:05:35 -------------------- Temat zamykam i przenoszę do Bangladeszu.
To jest wiadomość śmierci jeśli ją czytasz to znaczy że pozostało ci 30 sekund życia, więc lepiej zacznij się modlić. |
|
|
17.04.2013, 01:39:23
Post
#5
|
|
Grupa: Zarejestrowani Postów: 273 Pomógł: 52 Dołączył: 3.02.2013 Skąd: Przemyśl Ostrzeżenie: (0%) |
Ja dodam, że singletona powinno się unikać, tak samo jak konstrukcji goto lub funkcji eval()
Ten wzorzec nie jest mile widziany podczas tworzenia dobrego obiektowego kodu. Oczywiście ma on swoje zastosowanie, ale w 99,9% przypadków jest on stosowany w nieprawidłowy sposób. -------------------- Jeżeli moja wypowiedź Ci pomogła użyj przycisku
|
|
|
17.04.2013, 12:29:27
Post
#6
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
1. Jeśli ma to być singleton brakuje prywatnej/chronionej metody __clone 2. Przemyślałbym obsługę wielu baz, bo nawet jeśli tego nie przewidujemy to może taka potrzeba się pojawić. I pytanie, czy musi to być singleton bo przecież nie piszemy skryptu, gdzie w każdym pliku na samym początku DB::getInstance() 3. Współpracę klas oceniam fatalnie - poczytaj o wzorcach współpracy klas, na początek dependency injection, "wstrzykiwanie zależności" - tak to chyba po polsku się nazywa 4. Podobnie klasę _DSN - zobacz, jak tego używasz, najpierw tworzysz obiekt by wywołać konstruktor a potem dobierasz się do pól statycznych? Podstawą są gettery i settery a nie kombinowanie metodami statycznymi czy magicznymi. A jeśli już to powinieneś pobrać sobie ten cfg jedną metodą statyczną gdzie przekazujesz ten plik jako parametr, bez konieczności tworzenia obiektu. 1. Widziałem sporo wzorców Singleton i w żadnym nie spotkałem zastosowania metody __clone. 2. Nie rozumiem, czemu aktualny kod nie może nawiązywać połączenia z różnymi bazami?. Domyślam się, że chodzi o gotowy kod dla konstruktora klasy PDO i metodę, która będzie go wstrzykiwać w zależności od chęci użycia danej bazy. Akurat w moim przypadku wystarczy zmodyfikować ręcznie kod w pliku. 3. Poczytam. 4. Racja to było desperackie podejście - bez obycia w programowaniu obiektowym, człowiek ma mętlik w głowie jak przychodzi powiązać klasy . Ten post edytował q3trm 17.04.2013, 12:31:10 |
|
|
17.04.2013, 12:58:26
Post
#7
|
|
Grupa: Zarejestrowani Postów: 6 365 Pomógł: 1114 Dołączył: 30.08.2006 Ostrzeżenie: (0%) |
Ad1. Słabe przykłady miałeś
https://github.com/zendframework/zf1/blob/m...y/Zend/Auth.php -------------------- |
|
|
17.04.2013, 15:41:30
Post
#8
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Poprawiłem co nieco semantykę i wiązanie klasy _DSN z _PDOConnect.
Pokażę tylko _PDOConnect
Tylko teraz, powyższa implementacja klasy Singleton wymaga wywołania trzech metod: _PDOConnect::getInstance(); getClass_DSN(_DSN $DSN); getPDOClass(); Tak pomyślałem, że szkoda żeby konstruktor się marnował , więc stworzyłem implementację opartą na nawiązywaniu połączenia w konstruktorze - tak jak to było pierwotnie za implementowane.
_PDOConnect::getClass_DSN(_DSN $DSN); _PDOConnect::getInstance(); Teraz wystarczą tylko dwie metody i klasa gotowa do użycia. Co o tym sądzicie ma to ręce i nogi? |
|
|
22.04.2013, 14:50:21
Post
#9
|
|
Grupa: Zarejestrowani Postów: 348 Pomógł: 26 Dołączył: 8.10.2008 Skąd: Lublin Ostrzeżenie: (0%) |
Stworzyłem takiego dziwaka:
I jest nawet wygodny w użyciu. -------------------- Wolałem języki z rodziny C ale poszedłem na łatwizne...
|
|
|
Wersja Lo-Fi | Aktualny czas: 26.04.2024 - 21:01 |