Temat: Przekazanie wartości do zmiennej w klasie.

Czy ktoś pomoże raczkującemu amatorowi, który postanowił zacząć pisać na klasach :)

Nie wiem jak przekazać wartość zmiennej do zmiennej w klasie.

pobieram wartość z formularza za pomocą $_POST i dalej potrzebuję tą wartość użyć wewnątrz klasy.

<?php
$id_klienta = $_POST['id_klienta'];

class nowe_zlecenie_stale
{
//var $id_klienta = $_POST['id_klienta']; - to nie działa
//var $id_klienta = $id_klienta; - to też nie działa :(
var $id_klienta;
var $id_pracownika;
var $id_edytor;
var $tytul_zlecenia;

function formularz()
{
jakiś tam kod z formularzem
} //koniec formularz

} // koniec nowe_zlecenie_stale

$a = new nowe_zlecenie_stale;
$a->formularz();
?>

Temat: Przekazanie wartości do zmiennej w klasie.

function formularz($client_id)
{
echo $client_id;

}

$this->formularz($id_klienta);// w ramach klasy
jeśli po za
$a = new testClass();
$a->formularz($_POST["zmienne"]);

i możesz robić z tym co dusza zapragnieJakub Bartkiewicz edytował(a) ten post dnia 12.01.11 o godzinie 11:03

Temat: Przekazanie wartości do zmiennej w klasie.

W przypadku klasy którą przedstawiłeś, robi się to tak:

$a = new nowe_zlecenie_stale();

$a->id_klienta = $_POST['id_klienta']

$a->formularz();

A najlepiej - zapoznaj się z działaniem konstruktoró -> http://www.php.net/manual/en/language.oop5.decon.php

Temat: Przekazanie wartości do zmiennej w klasie.

Dzięki,

zrobiłem.

Temat: Przekazanie wartości do zmiennej w klasie.

Pośpieszyłem się jednak mi nie działa. Być może napisałem nie do końca jasno wcześniejsze pytanie. Podam prostszy przykład z pytaniem:
Jak spowodować, aby przekazać zmienną "$zmienna" z funkcji "test" to "test2", tak abym otrzymał w przeglądarce wynik "test: 2"

<?php

class testowa_klasa
{
function test()
{
$zmienna = 2;
}
function test2()
{
echo 'test: '.$zmienna;
}
}
$a = new testowa_klasa;
$a->test2()
?>

Temat: Przekazanie wartości do zmiennej w klasie.

W tym przypadku $zmienna z funkcji test() i $zmienna z funkcji test2() mają tyle wspólnego, że obie są zmiennymi i się tak samo nazywaja, ale to nie jest ta sama zmienna, to są zmienne lokalne odpowiednich funkcji.

Poczytaj o polach obiektów.

Temat: Przekazanie wartości do zmiennej w klasie.

<?php

class testowaKlasa
{
private $_zmienna = 0;
public function ustawZmienna($wartosc)
{
$this->_zmienna = (int) $wartosc;
}
public function zwrocZmienna()
{
return $this->_zmienna;
}
}

$cl = new testowaKlasa();
$cl->ustawZmienna(2);
echo 'test: '.$cl->zwrocZmienna();
?>

sugeruje poczytac o:
- MVC
- OOP w PHP5
- stardardzie nazewnictwa czy tez standardach kodowania

Temat: Przekazanie wartości do zmiennej w klasie.

Kamil Kieliszczyk:
<?php

>

class testowaKlasa
{
private $_zmienna = 0;
public function ustawZmienna($wartosc)
{
$this->_zmienna = (int) $wartosc;
}
public function zwrocZmienna()
{
return $this->_zmienna;
}
}

$cl = new testowaKlasa();
$cl->ustawZmienna(2);
echo 'test: '.$cl->zwrocZmienna();
?>

sugeruje poczytac o:
- MVC

1. Co ma do tego MVC?
2. Co to za podkreślnik i po co?
3. Wspominając o nomenklaturze podajesz przykład w języku polskim, ale ja z lenistwa też..
4. Genralnie ok, nie że się czepiam.

Przykład pierwszy (powinno być po angielsku, ale mi się nie chce):

<?php

$id_klienta = $_POST['id_klienta'];



class NoweZlecenieStale

{

 private $id_klienta;

 private $id_pracownika;

 private $id_edytor;

 private $tytul_zlecenia;



// ...



 function setIdKlienta($id_klienta)

 {

  $this->id_klienta = $id_klienta;

 }



 function getIdKlienta()

 {

  return $this->id_klienta;

 }



}



$a = new NoweZlecenieStale();

$a->setIdKlienta($id_klienta);

$a->formularz();

?>

Przykład drugi analogicznie. Komentarze są zbędne, wręcz szkodliwe. W żadnym razie nie używaj publicznych atrybutów klas, unikaj chronionych.

Do przeczytania:
- zasięg zmiennych,
- zmiennych instacyjnych,
- modyfikatorach widoczności,
- generalnie cokolwiek o OOP.

Wbrew temu co niektórzy opowiadają, teorii praktyka całkiem nie zastąpi, więc poczytaj trochę zanim się do czegoś zabierzesz.

Temat: Przekazanie wartości do zmiennej w klasie.

Łukasz Karpuć:
W żadnym razie nie używaj publicznych atrybutów klas, unikaj chronionych.

Z czystej przekory, gdyż?
Jestem po prostu ciekaw uzasadnienia, bo jeszcze nigdy nie słyszałem ani nie wyczytałem przekonującego argumentu.Michał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 20:31

Temat: Przekazanie wartości do zmiennej w klasie.

Michał Wachowski:

Łukasz Karpuć:
W żadnym razie nie używaj publicznych atrybutów klas, unikaj chronionych.

Z czystej przekory, gdyż?
Jestem po prostu ciekaw uzasadnienia, bo jeszcze nigdy nie słyszałem ani nie wyczytałem przekonującego argumentu.Michał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 20:31

1. Ogranicz wartość $id_klienta do [1, 7, 10].
2. Zmockuj obiekt tej klasy.
3. Stwórz klasę obiektów trwałych.
4. Zdefiniuj interfejs dla tej klasy.
5. Zaloguj ustawianie/pobieranie wartości tej zmiennej.

Potem zapytaj ponownie ;)

Temat: Przekazanie wartości do zmiennej w klasie.

Michał Wachowski:

Łukasz Karpuć:
W żadnym razie nie używaj publicznych atrybutów klas, unikaj chronionych.

Z czystej przekory, gdyż?
Jestem po prostu ciekaw uzasadnienia, bo jeszcze nigdy nie słyszałem ani nie wyczytałem przekonującego argumentu.Michał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 20:31

Nie używa się publicznych pól - hermetyzacja
Należy uważać z chronionymi polami, ponieważ jeśli pole chronione jest referencją do obiektu, można nieświadomie w podklasie zmienić ten obiekt, a to łamie zasadę hermetyzacji.

Temat: Przekazanie wartości do zmiennej w klasie.

Piotr Marian Gondek:

Nie używa się publicznych pól - hermetyzacja

E, nie zawsze to jest takie oczywiste - settery i gettery po prostu ułatwiają życie i są dobrą praktyką, ale generalnie różnica między $user->age a $user->getAge() jest dla mnie kosmetyczna i czasami (podkreślam!) powoduje więcej pisania bez specjalnego przyrostu elegancji. IMHO to kalka z Javy, która z kolei tę praktykę ściągnęła z C++, a w którym miało to duży sens, ponieważ nie istniały np. "magiczne" __set i __get, dzięki którymi możemy sobie w razie potrzeby stworzyć metody dostępu, ale w razie braku takiej potrzeby nie zaśmiecać sobie nimi kodu. Fajnie to ma Ruby zrobione, o ile dobrze rozumiem, można w nim w sposób przezroczysty "podmieniać" przypisanie na użycie settera (tak?).

Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.

Należy uważać z chronionymi polami, ponieważ jeśli pole chronione jest referencją do obiektu, można nieświadomie w podklasie zmienić ten obiekt, a to łamie zasadę hermetyzacji.

?
Nie rozumiem na czym polega "nieświadoma zmiana obiektu" w podklasie. Skoro projektant klasy daje podklasom dostęp do prywatnej zmiennej to daje i już. Takie zmienne umożliwiają fajne rzeczy, np. w ORM w Kohana3 można zdefiniować reguły walidacji modelu w polu chronionym $_rules, dzięki czemu każdemu modelowi można nadać inne reguły przy posiadaniu jednej metody check() w rodzicu.Rafał Nowak edytował(a) ten post dnia 12.01.11 o godzinie 21:20

Temat: Przekazanie wartości do zmiennej w klasie.

Rafał Nowak:

Piotr Marian Gondek:

Nie używa się publicznych pól - hermetyzacja

E, nie zawsze to jest takie oczywiste - settery i gettery po prostu ułatwiają życie i są dobrą praktyką, ale generalnie różnica między $user->age a $user->getAge() jest dla mnie kosmetyczna i czasami (podkreślam!) powoduje więcej pisania bez specjalnego przyrostu elegancji. IMHO to kalka z Javy, która z kolei tę praktykę ściągnęła z C++, a w którym miało to duży sens, ponieważ nie istniały np. "magiczne" __set i __get, dzięki którymi możemy sobie w razie potrzeby stworzyć metody dostępu, ale w razie braku takiej potrzeby nie zaśmiecać sobie nimi kodu. Fajnie to ma Ruby zrobione, o ile dobrze rozumiem, można w nim w sposób przezroczysty "podmieniać" przypisanie na użycie settera (tak?).

Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.

Settery i gettery to są metody, które operują na polach, tak? Wiec nie operujemy bezpośrednio na publicznym polu. To, że zapis jest identyczny, to już inna bajka.

Należy uważać z chronionymi polami, ponieważ jeśli pole chronione jest referencją do obiektu, można nieświadomie w podklasie zmienić ten obiekt, a to łamie zasadę hermetyzacji.

?
Nie rozumiem na czym polega "nieświadoma zmiana obiektu" w podklasie. Skoro projektant klasy daje podklasom dostęp do prywatnej zmiennej to daje i już. Takie zmienne umożliwiają fajne rzeczy, np. w ORM w Kohana3 można zdefiniować reguły walidacji modelu w polu chronionym $_rules, dzięki czemu każdemu modelowi można nadać inne reguły przy posiadaniu jednej metody check() w rodzicu.Rafał Nowak edytował(a) ten post dnia 12.01.11 o godzinie 21:20

To akurat jest do wypowiedzi wyżej. @Michał nie czytał nigdzie o tym, że pola prywatne mogą być niebezpieczne. Ja to przeczytałem w 'Java Podstawy. Wydanie VIII'.

BTW: moja wypowiedź porusza raczej temat lenistwa programisty. Szybciej jest napisać protected $name, niż stworzyć pole prywatne i mutator'a oraz accessor'a do niego, prawda? A to ciągnie za sobą konsekwencje, dlatego używanie pól prywatnych MOŻE BYĆ NIEBEZPIECZNE, a nie zakazane.

Temat: Przekazanie wartości do zmiennej w klasie.

Teraz wyjdę na bluźniercę, nicponia i osobę co gada, a nie umie :)

1,2,3,4 i 5 - da się, kwestię czy będzie ładnie wyglądać pomijam (jak ktoś ładnie pisze, to i to ładnie napisze).

Co do enkapsulacji - idea szczytna, jednak życie nie raz mi udowodniło, że ignorancja i głupota ludzka nie zna granic. :)

Podmiany referencji nie rozumiem - skoro trzymasz się enkapsulacji, to powinieneś mieć:

class A { 

private $objC;

function setObjC(C &$objC) {

$this->$objC = $objC;

}

}

(oj ucieło kwałek)
Jeśli ktoś ci podmieni C na inne C, to widocznie ma tak być.
Jeśli ktoś ci podmieni C na inną klasę - to cóż, widocznie nie powinien dotykać programu.

---

No i Rafał napisał szybciej.

@Piotr - nie napisałem że nie czytałem, po prostu ten argument mnie nie przekonuje. Jak ktoś ma talent - to i privaty spieprzy.

Idąc dalej za twoimi wypowiedziami - możemy mieć getter i setter o mylącej nazwie:

public function setA($foo) {

$this->b = $foo;

}

public function getA() {

return $this->c;

}

I oto w tym momencie można by powiedzieć: publiczne settery są niebezpieczne :)
PS: i gettery też :DMichał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 21:40

Temat: Przekazanie wartości do zmiennej w klasie.

Wybacz, albo robisz sobie mało zabawne jaja, albo ta dyskusja nie ma sensu :)

Temat: Przekazanie wartości do zmiennej w klasie.

Proceduralnie też się da, ale nie o to chodzi, żeby się dało, tylko żeby dało się najprościej i najczyściej jak się da.

Interfejsu nie da się zdefiniować.

Zmienne mają przechowywać dane - z punktu widzenia programisty nie powinno mieć znaczenia, jak je obiekt przechowuje, tylko jakie operacje wykonuje. W przypadku obiektów, które są de facto strukturami, to może i być jakoś tam uzasadnialne - tylko po co robić takie wyjątki? Szczególnie, że jeśli będziemy potrzebować dodatkowych operacji w momencie przypisania wartości zmiennej, to trzeba będzie zaangażować niewydajne magiczne metody.

Prosty przykład.

class Foo

{

  public $number;

}



$foo = new Foo();

$foo->number = 1;



// Co jeśli wymyślimy klasy

abstract class Number

{

 abstract function getValue();

}

class Decimal extends Number{}

class Float extends Number{}

// z jakiegoś tam powodu.

// Pomijam implementację.



$foo->number = $decimal->getValue(); // ?? bez sensu



class Bar

{

 private $number;



 public function setNumber($x)

 {

  if( $x instanceof Number )

  {

   $this->number = $x->getValue();

  }

  else

  {

   $this->number = $x;

  }

 }

}



$bar = new Bar();

$bar->setNumber(1);

$bar->setNumber($decimal);

$bar->setNumber($float);

Kod ma działać i być czytelny. Nie "lub czytelny", albo "i ewentualnie czytelny".Łukasz Karpuć edytował(a) ten post dnia 12.01.11 o godzinie 21:45

Temat: Przekazanie wartości do zmiennej w klasie.

Piotr Marian Gondek:
Wybacz, albo robisz sobie mało zabawne jaja, albo ta dyskusja nie ma sensu :)

Chyba racja.

Temat: Przekazanie wartości do zmiennej w klasie.

Piotr Marian Gondek:

Rafał Nowak: Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.

Settery i gettery to są metody, które operują na polach, tak? Wiec nie operujemy bezpośrednio na publicznym polu. To, że zapis jest identyczny, to już inna bajka.

Ok, ale czasami to zwyczajnie wygodne i sensowne - np jeśli mamy klasę Klient, który ma imię i nazwisko, to jak proponujesz ustawianie danych osobowych tegoż klienta? setName, setSurname? Moim zdaniem istnieją elementy, które są właściwościami obiektu i do których dostęp jest czasem potrzebny. W takich wypadkach - używając PHP - moim zdaniem niepotrzebne jest pisanie metod, najlepiej zrobić te pola po prostu publiczne, a ewentualnie w razie potrzeby "zamaskować" je poprzez użycie __set i __get.

BTW: moja wypowiedź porusza raczej temat lenistwa programisty. Szybciej jest napisać protected $name, niż stworzyć pole prywatne i mutator'a oraz accessor'a do niego, prawda? A to ciągnie za sobą konsekwencje, dlatego używanie pól prywatnych MOŻE BYĆ NIEBEZPIECZNE, a nie zakazane.

Ale dalej nie rozumiem na czym polega niebezpieczeństwo, chętnie się doedukuję :)

Temat: Przekazanie wartości do zmiennej w klasie.

Łukasz Karpuć:
Proceduralnie też się da, ale nie o to chodzi, żeby się dało, tylko żeby dało się najprościej i najczyściej jak się da.

Interfejsu nie da się zdefiniować.

To jest zdanie, które najbardziej mnie przekonuje.

Natomiast prawdą jest również, że istnieje wiele zastosowań w PHP, w których rzeczywiście obiekty są pewnego rodzaju strukturami. Rozumiem argument z rozwojem interfejsu, rozumiem argument z utrzymaniem spójności. Ale skoro coś po prostu jest właściwością, to czy nie wydaje wam się, że _naturalniej_ jest traktować to jako właśnie jako właściwość obiektu? Może jestem spaczony, ale dla mnie bardziej naturalny jest zapis $user->name niż $user->getName() :)

Wspomniałeś też o wydajności metod magicznych - posiadasz może jakieś materiały na ten temat? Chętnie poczytam.

Temat: Przekazanie wartości do zmiennej w klasie.

Rafał Nowak:

Piotr Marian Gondek:

Rafał Nowak: Więc hermetyzacja: tak, ale skoro mamy do czynienia ze skryptowym językiem to ułatwmy sobie życie w przypadkach trywialnych i nie udawajmy, że programujemy w C++.

Settery i gettery to są metody, które operują na polach, tak? Wiec nie operujemy bezpośrednio na publicznym polu. To, że zapis jest identyczny, to już inna bajka.

Ok, ale czasami to zwyczajnie wygodne i sensowne - np jeśli mamy klasę Klient, który ma imię i nazwisko, to jak proponujesz ustawianie danych osobowych tegoż klienta? setName, setSurname? Moim zdaniem istnieją elementy, które są właściwościami obiektu i do których dostęp jest czasem potrzebny. W takich wypadkach - używając PHP - moim zdaniem niepotrzebne jest pisanie metod, najlepiej zrobić te pola po prostu publiczne, a ewentualnie w razie potrzeby "zamaskować" je poprzez użycie __set i __get.

Mutator'y i accessor'y - tak, pola publiczne - nie. To moja opinia jako programisty, nie zmuszę Cię do niej ;)
Czasem, gdy potrzebuję stworzyć strukturę (której w PHP nie ma), to tworzę klasę z polami publicznymi. Jednak to specyficzny i rzadki przypadek.

BTW: moja wypowiedź porusza raczej temat lenistwa programisty. Szybciej jest napisać protected $name, niż stworzyć pole prywatne i mutator'a oraz accessor'a do niego, prawda? A to ciągnie za sobą konsekwencje, dlatego używanie pól prywatnych MOŻE BYĆ NIEBEZPIECZNE, a nie zakazane.

Ale dalej nie rozumiem na czym polega niebezpieczeństwo, chętnie się doedukuję :)

Java Podstawy, Wydanie VIII. Cay S. Horstmann, Gary Cornell; strona 221