Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 1 Dołączył: 24.06.2010 Skąd: Sopot Ostrzeżenie: (0%)
|
Hej,
mam sobie klasę DB, która zajmuje się łączeniem z bazą danych oraz obsługą błędów. Gdy chcę zrobić coś z danymi tworzę nową klasę rozszerzającą klasę DB i w niej umieszczam odpowiednią metodę. Zależy mi na możliwie dużej wydajności, stąd nie tworzę uniwersalnej klasy ze wszystkimi możliwymi metodami, ale każdy rodzaj działania na bazie wymaga oddzielnej klasy, żeby była ona możliwie najkrótsza. Klasa DB: http://wklej.to/O7pd Przykładowa klasa pobierająca dane użytkownika: http://wklej.to/Glmo Przykładowe zastosowanie: http://wklej.to/3TPK Przykładowy wynik: http://wklej.to/UOtk Problem pojawia się, gdy chcę skorzystać z dwóch różnych operacji na bazie – niepotrzebnie wtedy uruchamiam dwie instancje klasy DB, czyli niepotrzebnie zajmuję pamięć i wielokrotnie łączę się z bazą zamiast skorzystać z jednego połączenia. Chciałem zrobić klasę DB jako singleton i tu się pojawia pytanie: czy mogę rozszerzać singletona? Jak to wtedy wywołać? Chodzi o to, żeby mieć jedną instancję klasy bazowej DB, z którego korzystać może wiele innych klas ją rozszerzających. Dzięki i pozdr. |
|
|
|
![]() |
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%)
|
Zależy co masz na myśli pisząc: "rozszerzać singletona".
Co do samego wywołania, tak samo jak z konstruktorem parent:: i jedziesz ;] Mam nadzieję, że klasa getuser jest tylko przykładowa i nie rozbijesz wszystkiego na takie malutkie klasy. |
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 1 332 Pomógł: 294 Dołączył: 12.10.2008 Skąd: Olkusz Ostrzeżenie: (0%)
|
jak masz takie same metody publiczne czy chronione u rodzica to nie musisz ich nadpisywać przy potomkach - dlatego potomek tutaj DB_getUser nie musiał mieć definicji __construct()...
jeśli chcesz mieć jeden uchwyt do a w zasadzie tworząc nowe instancje obiektu to daleko od singleton'a - jeśli tak chciałbyś zrobić to klasa bazy po prostu obsługuje bazę i instancje tej klasy przekazujesz innym klasom gdzie z db zwracasz uchwyt - oczywiście w modelu singleton klasę tworzy się tak by zawsze był zwracany stary obiekt a nie nowy [chyba, że nie istnieje...] - obiekt taki najczęściej jest zapamiętany w zmiennej statycznej... ale na to co Ty zrobiłeś zamiast singleton'a to zrób deczko inny konstruktor i inaczej przechowuj zmienne i uchwyt do bazy - w zmiennych statycznych - jeśli one są ustawione to w konstruktorze nic nie rób... w metodach uchwyt do bazy odwołuj się do zmiennej statycznej - oczywiście zdefiniuj je u najwyższego rodzica by potomkowie mieli także dostęp do tych zmiennych statycznych... czyli zamiast:
możesz zrobić:
no i oczywiście uchwyt do bazy we wszystkich klasach także potomnych masz pod self::$connection Ten post edytował zegarek84 9.08.2010, 11:12:02 |
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 589 Pomógł: 91 Dołączył: 22.05.2008 Skąd: Gliwice Ostrzeżenie: (0%)
|
Klasa do obsługi bazy danych nie powinna być imho singletonem, bo istnieje przecież możliwość, że jedna aplikacja będzie korzystała z kilku baz. Moim zdaniem powinieneś robić to tak:
Twoja klasa DB_getUser nie powinna dziedziczyć od DB bo ona właściwie nie rozszerza możliwości tej klasy, jest to zwykły model. |
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%)
|
Dokładnie, obsługą samej bazy powinna zajmować się oddzielna klasa, natomiast główny model danych to powinna być inna klasa, która połączenie z bazą pobiera w konstruktorze i to ona dopiero obsługuje zapytania i błędy natomiast poszczególne metody dostępu do danych mogą być rozszerzeniem tej klasy. Moim zdaniem dobrze przyjąć koncepcje, że jedna tabela w bazie = jeden model zawierający metody korzystające z tej tabeli. Bo inaczej jak? Potężna klasa do obsługi każdego "select * from tabela"? Get user może wyglądać tak:
Spójna koncepcja nazewnictwa i komentarze też mile widziane. |
|
|
|
![]() ![]() |
|
Aktualny czas: 10.06.2026 - 13:11 |