Deklarowanie zmiennych tablicy OOP Opcje

[kowal88]

Witajcie, OOP zaczynam dopiero dlatego proszę o wyrozumiałość . 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

[PHP] pobierz, plaintext 
class User {
  private $id;
  private $other;
 public function __construct() {
 
  $this->id = null;
$this->other = array ('username' =>'', 'pass' => '', 'mail' => '');
 
}
 
$u = new User();
$u->username = 'kowal';
$u->password = "kowal123';
 
}
[PHP] pobierz, plaintext 

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ć , 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?

Ten post edytował kowal88 26.12.2012, 00:33:45

[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
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.

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.

(nie chce w klasie mieć pól publicznych)

Korzystanie z takiej tablicy tworzy de facto właściwości publiczne.

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:

[PHP] pobierz, plaintext 
$object = new Object;
echo $object->privateProperty;
[PHP] pobierz, plaintext 

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:

[PHP] pobierz, plaintext 
class User {
 
  private $id;
  private $other;
 
  public function __construct() {
    $this->id = null;
    $this->other = array ('username' =>'', 'pass' => '', 'mail' => '');
  }
}
 
$u = new User();
$u->username = 'kowal';
$u->password = "kowal123";
 
echo $u->password; // 1
echo $u->username; // 2
echo $u->id; // 3
[PHP] pobierz, plaintext 

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ć:

[PHP] pobierz, plaintext 
$u->other['username'] = 'kowal';
[PHP] pobierz, plaintext 

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

Ten post edytował adbacz 5.01.2013, 15:11:19

[sazian]

może inaczej

[PHP] pobierz, plaintext 
$u = new User();
$u->username = 'kowal';
$u->password = "kowal123";
var_dump($u);
[PHP] pobierz, plaintext 

i sam zobacz co siedzi w twoim obiekcje