Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP] Pierwsza Klasa
Forum PHP.pl > Forum > Przedszkole
Grafnastyk
Witam, czy mógłby mi ktoś wyjaśnić dlaczego moja funkcja use_monster zwraca tylko pierwszą zmienną? Domyślam się, że błąd jest banalny, ale nigdzie nie mogę znaleźć rozwiązania a błędu nie wyrzuca mi żadnego.

  1. <?php
  2.  
  3. class Monster
  4. {
  5. public
  6. $name,
  7. $hp,
  8. $def,
  9. $atk;
  10.  
  11. public function Create_monster($m_name, $m_hp, $m_def, $m_atk)
  12. {
  13. $this->name = $m_name;
  14. $this->hp = $m_hp;
  15. $this->def = $m_def;
  16. $this->atk = $m_atk;
  17.  
  18. }
  19.  
  20. public function use_monster()
  21. {
  22. return $this->name;
  23. return $this->hp;
  24. return $this->def;
  25. return $this->atk;
  26.  
  27.  
  28. }
  29.  
  30. }
  31.  
  32. $monster1 = new Monster;
  33.  
  34. $monster1->Create_monster('Troll',100,100,100);
  35.  
  36. echo $monster1->use_monster();
markonix
A jak sobie wyobrażasz, żeby zwróciło Ci jednocześnie kilka wartości? Po przecinku?
viking
return wychodzi natychmiast z metody. Najlepiej zwróć tablicę.
Natomiast poczytaj trochę o PSR i zdecyduj się na jedno nazewnictwo, najlepiej camelCase.
leonpro778
Nazewnictwo to aż nie taki wielki problem (chociaż też są przyjęte pewne standardy). Zacznij lepiej od zapamiętywania pewnych przyjętych "nawyków" przy programowaniu obiektowym.

1. Do każdego pola powinna być przypisana metoda GET i SET.
2. Pola metody powinny być prywatne a dostęp do nich (poprzez metody GET i SET) niech będzie publiczne.
3.Metodę Create_monster wrzuć w konstruktor.
4. Odnośnie nazewnictwa:
Nazwy pól, czyli hp, att nazywamy z _ na początku. Czyli $this->_mp
Nazwy metod, czyli przykładowo jakis GET. Pierwsza litera jest mała, czyli getHp()
Nazwa obiektu z dużej litery, czyli tak jak masz u siebie class Monster

I tyle jak na początek :-)

Odnośnie problemu - dostęp do tych danych, pobieraj wtedy kiedy ich potrzebujesz. I niestety nie możesz zrobić tego cztery razy pisząc return :-)
Pyton_000
Torchę popłynąłeś...

1. Gettery i Settery (bo tak to się nawzyaw) nie są wymagane, a czasami wręcz nie potrzebne.
2. _ się nie używa do określania widoczności properties.

Odnoścnie "nazewnictwa kodu" oraz tego co i jak polecam zapoznać się z
http://www.php-fig.org/psr/psr-1/
http://www.php-fig.org/psr/psr-2/
Boshi
"Troche.." on zatonął.

prefixów w postaci kresek się nie używa, akcesory nie są potrzebne zawsze, przykład Value obiect..
leonpro778
Tak trochę to nie ja "popłynąłem" co WY mnie nie zrozumieliście.

Po pierwsze:
Nic nie pisałem o GETTERACH i SETTERACH. To, że użyłem nazwy GET i SET wynika tylko właśnie z tego, że w jakiś sposób trzeba zmienną w pewien sposób "zmodyfikować" i do tego służy metoda, którą nazwałem sobie SET (popatrzcie na przykład jaki podałem w nazewnictwie). Mój błąd, że nie napisałem poprawnie.

Po drugie:
Prefiks w postaci _ przed zmienną ma określać WIDOCZNOŚĆquestionmark.gif Gdzie ja tak napisałem? Napisałem tylko, że pola powinny być prywatne a metody publiczne. Oczywiście taki znak przed zmienną pomaga w późniejszej identyfikacji zmiennej ale nigdzie nie napisałem, że _ zmienia widoczność.
viking
Czyli właśnie setter.
_ już od wielu lat się nie używa. I dobrze pyton napisał choć może skrótowo.
markuz
  1. <?php
  2.  
  3. namespace Game;
  4.  
  5. class Monster
  6. {
  7. private $name;
  8. private $attack;
  9. private $defense;
  10. private $life;
  11.  
  12. public function __construct(string $name, int $attack, int $defense, int $life)
  13. {
  14. $this->name = $name;
  15. $this->attack = $attack;
  16. $this->defense = $defense;
  17. $this->life = $life;
  18. }
  19.  
  20. public function getName(): string
  21. {
  22. return $this->name;
  23. }
  24.  
  25. public function getAttack(): int
  26. {
  27. return $this->attack;
  28. }
  29.  
  30. public function getDefense(): int
  31. {
  32. return $this->defense;
  33. }
  34.  
  35. public function getLife(): int
  36. {
  37. return $this->life;
  38. }
  39. }


1. Obiekt tworzymy przez konstruktor a nie dodatkową metode.
2. Używamy normalnych nazw, bez żadnych skrótów które mogą wprowadzić w błąd.
3. Domyślnie każda właściwość powinna być prywatna
SmokAnalog
Cytat(leonpro778 @ 10.12.2017, 08:51:07 ) *
Tak trochę to nie ja "popłynąłem" co WY mnie nie zrozumieliście.

Poczytałeś o dobrych nawykach, ale nie doczytałeś, że trzeba je stosować z głową. Getterów i setterów się używa tylko tam, gdzie są potrzebne. A z tym dolnym podkreśleniem to niektórzy mają taką zasadę, ale moim zdaniem jest idiotyczna. A już mówić o niej jak o jakiejś prawdzie objawionej to jakiś kosmos.
leonpro778
Cytat(SmokAnalog @ 10.12.2017, 13:14:36 ) *
Poczytałeś o dobrych nawykach, ale nie doczytałeś, że trzeba je stosować z głową.

Co jest błędnego w moim rozumowaniu?

Cytat(SmokAnalog @ 10.12.2017, 13:14:36 ) *
Getterów i setterów się używa tylko tam, gdzie są potrzebne.

Wyjaśnijmy jedno, czym dla Ciebie jest:
getAttack() {
return $this->_att;
}

Cytat(SmokAnalog @ 10.12.2017, 13:14:36 ) *
A z tym dolnym podkreśleniem to niektórzy mają taką zasadę, ale moim zdaniem jest idiotyczna.

Framework Zend - tam długo stosowali taką zasadę. Czy ja wiem czy jest to taka idiotyczna zasada?questionmark.gif

Cytat(SmokAnalog @ 10.12.2017, 13:14:36 ) *
A już mówić o niej jak o jakiejś prawdzie objawionej to jakiś kosmos.

Heh, czy ja pisałem o jakiejś prawdzie objawionej?
nospor
Cytat
Framework Zend - tam długo stosowali taką zasadę. Czy ja wiem czy jest to taka idiotyczna zasada?
Skolo klucz z twojej wypowiedzi: STOSOWALI - czas przeszly
Kiedys ludzie przez wieki zyli w jaskiniach....

Teraz mamy PSR ktore standaryzuje pewne rzeczy, ale zawsze znajdzie sie taki ktos jak ty, kto nie ma internetu a jak juz sie dorwie do modemu u kogos to szerzy herezje sprzed stu lat na lewo i prawo wink.gif
viking
Wpisz sobie
  1. <?php
  2. class Test {
  3. private $att;
  4. private $def;
  5.  
  6. }


W Netbeans wciśnij alt+insert - getter & setter. Masz wygenerowane wszystkie metody tylko że nazewnictwo leży. Podkreślenie owszem, stosowało się mocno w ZF1, tyle że gdybyś tak teraz oznaczał wszystko w ten sposób miałbyś potężne problemy np z hydratorem (który swoją drogą stosowałem praktycznie od jego wymyślenia również w projektach ZF1 i wymagało przemyślenia od nowa zwłaszcza nazw encji - modeli).
leonpro778
Cytat(nospor @ 10.12.2017, 14:21:05 ) *
Skolo klucz z twojej wypowiedzi: STOSOWALI - czas przeszly
Kiedys ludzie przez wieki zyli w jaskiniach....

Dobra, zadałem sobie trudu aby odnaleźć ich bieżącą dokumentację:
Cytat
For variables that are declared with private or protected visibility, the first character of the variable name MAY be a single underscore. This is the only acceptable application of an underscore in a variable name, and is discouraged (as it makes refactoring to public visibility more difficult). Member variables declared with public visibility SHOULD NOT start with an underscore.

smile.gif


Oooo, i w końcu dobry argument:
Cytat(viking @ 10.12.2017, 14:38:01 ) *
Wpisz sobie
  1. <?php
  2. class Test {
  3. private $att;
  4. private $def;
  5.  
  6. }


W Netbeans wciśnij alt+insert - getter & setter. Masz wygenerowane wszystkie metody tylko że nazewnictwo leży. Podkreślenie owszem, stosowało się mocno w ZF1, tyle że gdybyś tak teraz oznaczał wszystko w ten sposób miałbyś potężne problemy np z hydratorem (który swoją drogą stosowałem praktycznie od jego wymyślenia również w projektach ZF1 i wymagało przemyślenia od nowa zwłaszcza nazw encji - modeli).

Masz rację z generowaniem nazw. Ja jednak używam PHPStorm smile.gif Efekt podobny dlatego i tak nazwy sobie piszę praktycznie od podstaw. Odpiszę dokładnie wieczorem bo z t telefonu piszę i ciężko jak cholera.
nospor
Nie bardzo rozumiem, o czym ma swiadczyc ten wycinek z dokumetnacji. Przeciez wyraznie napisali ze sie z tego wycofuja. Trzymaja tylko jako relikt przeszlosci.

Dostales linki do PSR - z nimi sie zapoznaj bo to jest to co teraz obowiazuje
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.