Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Deklarowanie zmiennych tablicy OOP
Forum PHP.pl > Forum > PHP > Object-oriented programming
kowal88
Witajcie, OOP zaczynam dopiero dlatego proszę o wyrozumiałość smile.gif. Spotkałem się z taką 'techniką' deklarowań zmiennych i chciałbym się dowiedzieć czy jest ona właściwa, czy raczej nie powinno się tak robić. ok powiedzmy, że mamy klase user

  1. class User {
  2. private $id;
  3. private $other;
  4. public function __construct() {
  5.  
  6. $this->id = null;
  7. $this->other = array ('username' =>'', 'pass' => '', 'mail' => '');
  8.  
  9. }
  10.  
  11. $u = new User();
  12. $u->username = 'kowal';
  13. $u->password = "kowal123';
  14.  
  15. }


i właśnie chodzi mi o zmienną other której przypisuje typ tablicowy i cała reszta właściwości obiektu user ląduje w tej jednej tablicy. Jest to na tyle wygodne, że nie muszę do każdej zmiennej robić funkcji pobierającej wartość pytanie tylko czy to właśnie tak może być smile.gif, a jeżeli nie to dlaczego i jak rozwiązać takie coś (nie chce w klasie mieć pól publicznych)

edit: aha i jeszcze pytanie obsługi użytkownika np. zalogowania go. Czy funkcja pobierania usera z bazy powinna być w klasie user czy w klasie baza? smile.gif
jeremiash
W sumię ja też zacząłem dosyć niedawno zabawę z OOP, więc moją wypowiedź traktuj może jako alternatywę a nie wytyczne... mimo to podziele się swoimi spostrzeżeniami, skoro brak innych chętnych smile.gif
Po pierwsze zalecam korzystanie z PDO. Jeśli chcesz mieć połączenie tylko wewnątrz klasy i to ze zmiennymi głównie prywatnymi, to innego rozwiązania niż to któe robisz nie widzę. Trudno mi wyobrazić sobie poważną aplikację z kilkoma tysiącami kodu pisaną w ten sposób, ale... Nie rozumiem dlaczego nie chcesz używać funkcji publicznych w połączeniu z PDO. Wówczas masz już rozwiązany problem z filtracją danych w zapytaniach bady danych. Przecież dodatkowo możesz zaimplementować interfejs / interfejsy i jest bezpiecznie, przejrzyście , miło ...
Crozin
Jest to bardzo zła technika. Tracisz wsparcie ze strony IDE oraz narzędzi dokumentujących i analizujących kod, a o wygodnej kontroli nad wprowadzonymi danymi można zapomnieć. Kod jest podatny na masę błędów wynikających z dynamicznej natury PHP-owskich tablic. O problemach wynikających ze stosowania takich potworków można by napisać niemały esej. Co zyskujesz w zamian? Absolutnie nic.
Cytat
Jest to na tyle wygodne, że nie muszę do każdej zmiennej robić funkcji pobierającej wartość
PPM -> Source -> Generate Getters and Setters -> Select All (bądź wybierz tylko istotne) -> OK. Zbyt wiele czasu na to nie poświęcisz.
Cytat
(nie chce w klasie mieć pól publicznych)
Korzystanie z takiej tablicy tworzy de facto właściwości publiczne.
Cytat
Czy funkcja pobierania usera z bazy powinna być w klasie user czy w klasie baza?
Ani w jednej, ani w drugiej. Obiekt klasy User powinien reprezentować pojedynczego użytkownika, a obiekt "bazy" jest raczej odpowiedzialny za zwracanie danych z bazy w surowej postaci. Takie coś powinno zostać wykonane w osobnym obiekcie, który korzystając z bazy danych utworzy i zwróci obiekt typu User.
Google: PHP ORM - przede wszystkim Doctrine.
adbacz
Nie chcesz mieć w klasie pól publicznych? Nie chce Ci sie robić setterów i getterów dla klasy? W takim razie mam prawo nazwać Cię troszke leniem.

Jeśli zaczynasz zabawę z OOP to powinieneć wiedzieć, że do prywatnej właściwości klasy nie można odwołać się tak:
  1. $object = new Object;
  2. echo $object->privateProperty;

Taku skrypt spowoduje pojawienie się błędu w drugiej linijce, pod założeniem, że właściwość privateProperty jest prywatna.

Teraz przeanalizujmy Twój kod klasy User:
  1. class User {
  2.  
  3. private $id;
  4. private $other;
  5.  
  6. public function __construct() {
  7. $this->id = null;
  8. $this->other = array ('username' =>'', 'pass' => '', 'mail' => '');
  9. }
  10. }
  11.  
  12. $u = new User();
  13. $u->username = 'kowal';
  14. $u->password = "kowal123";
  15.  
  16. echo $u->password; // 1
  17. echo $u->username; // 2
  18. echo $u->id; // 3

Powiedz mi, w którym miejscu pokaże się błąd? 1, 2 czy 3? W trzecim, ponieważ tylko ta właściwość została zdeklarowana jako prywatna, i tylko ta została zdeklarowana w całej klasie jako jej! Pozostałe dwie stworzyłeś w liniach tuż pod stworzeniem nowego obiektu klasy User, czyli na poczekaniu.

Dlaczego tak? Ponieważ w konstruktorze do właściwości other przypisywana jest tablica, która nic nie wnosi. Ona jest wartością pola other, i nic więcej. Nie da się przypisać tam wartości zzewnątrz obiektu User, tak jak to rozumujesz.

Czyli idąc tym tokiem, musiałoby dać się zrobić coś takiego, by we właściwości other pod indeksem username dało się cokolwiek umieścić:
  1. $u->other['username'] = 'kowal';

Ale tak sie nie da, ponieważ właściwość other jest właściwością prywatną.

Aby przypisac tam jaką kolwiek wartość (zwarzając, że jest to prywatna właściwość) musisz stworzyć settera lub metodę, która ustawi wartość nie koniecznie taką, jaką jej prześlesz.

Mam nadzieję, że wystarczająco wyjaśniłem to zagadnienie. Polecam czytanie dobrych artykułów, a jeśli już coś znajdziesz co ktoś inny napisał, tak jak ta 'technika' wyżej pokazana, to sprawdź, czy aby na pewno działa. Pozdrowienia, i powodzenia w nauce smile.gif
sazian
może inaczej
  1. $u = new User();
  2. $u->username = 'kowal';
  3. $u->password = "kowal123";

i sam zobacz co siedzi w twoim obiekcje
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.