Witam wszystkich bardzo serdecznie;)

Mam oto taki kod:

[PHP] pobierz, plaintext 
<?php
 
ob_start();
 
try
{
	@ $db = new PDO('mysql:host=localhost;dbname=baza', 'user', 'haslo');
}
catch(PDOException $e)
{
	die('Brak połączenia');
 
}
 
 
class wybierz
{
public function dalej()
{
 
 
$bb = $db->query('Select nazwa from tabela order by pole ASC');
 
$wybierz = $bb->fetch();
 
echo $wybierz['nazwa'];
 
}
 
}
 
$a = new wybierz();
$a->dalej();
 
 
 
ob_end_flush();	
 
?>
[PHP] pobierz, plaintext 

Gdy wchodzę na plik wywala mi taki błąd:
Fatal error: Call to a member function query() on a non-object in /adres_do_pliku on line 22
Dlaczego?

Proszę o pomoc.

Pozdrawiam:)

$db nie jest widzialny w klasie 'wybierz' i dlatego tam nie istnieje jako obiekt PDO.
Musisz go przekazać tej klasie.

Czy mógłbyś mi powiedzieć jak go przekazać?
Dopiero zaczynam swoją przygodę z OOP więc byłbym bardzo wdzięczny za pomoc.

Jakoś tak mniej więcej:

[PHP] pobierz, plaintext 
<?php
ob_start();
try
{
 $db = new PDO('mysql:host=localhost;dbname=baza', 'user', 'haslo');
}
catch(PDOException $e)
{
 die('Brak połączenia');
}
 
class wybierz
{
 private $db;
 public function __construct(PDO $db)
 {
  $this->db = $db;
 }
 
 public function dalej()
 {
   $bb = $this->db->query('Select nazwa from tabela order by pole ASC');
   $wybierz = $bb->fetch();
   echo $wybierz['nazwa'];
  }
}
 
$a = new wybierz($db);
$a->dalej();
 
ob_end_flush();	
?>
[PHP] pobierz, plaintext 

ps. nie ten dział

Działa Dziękuję za pomoc:)

Naucz się korzystać z dziedziczenia, przecież nie będziesz przekazywał lub tworzył obiektu DB za każdym razem, gdy tworzysz nowy model danych, model danych powinien dziedziczyć połączenie z bazą, klasa np. "model_danych_artykuły" dziedziczy wszystkie podstawowe metody i pola z klasy "baza_danych", która obsługuje bazę, a w klasie "model_danych_artykuły" tylko definiujesz jakieś skomplikowane zapytania (bo proste są już zaimplementowane w klasie baza_danych), klasy i metody pobierające dane z bazy są jej integralną częścią i nie powinny funkcjonować jako samodzielne obiekty.

@Pilsener: ale stek bredni...
1) Utworzenie 10 obiektów ma skutkować nawiązaniem 10 połączeń do bazy danych?
2) Tzw. Model to nie tylko baza danych... będzie miał model pobierający dane z XMLa, to też będzie łączyć się z bazą danych?
3) Niby jakie metody mogłoby dziedziczyć "ModelDanychArtykuły" po "ModelDanych"? Nawet najprostszego wybierania jednego elementu po kluczu głównym nie da się zaimplementować
4) To Tobie radzę nauczyć się korzystania z dziedziczenia, bo chyba nie uważasz, że telefonistka dziedziczy po telefonie?

@ziomek32: zabrakło Ci jeszcze obsługi wyjątków wyrzucanych przez metody PDO::Query() oraz PDOStatement::fetch() jak również i ta klasa "Wybierz" jest trochę bez sensu (a przynajmniej jej nazwa...) - od razu dodam, że metoda Wybierz::dalej() nie powinna raczej niczego wyświetlać tylko zwracać dane.

btw: po co Ci ten die(...)? Wyjątek zawiera dużo więcej informacji, niż jakiś komunikat "nie udało się"

Przecież napisałem, za każdym razem ma powtarzać taki kod:

[PHP] pobierz, plaintext 
private $db;
public function __construct(PDO $db)
{
this->db = $db;
}
[PHP] pobierz, plaintext 

? A jak będzie chciał zmienić sterownik? Nic nie pisałem na temat ilości połączeń. Jak potrzebuję np. dostępu do tabeli artykuły to robię:

[PHP] pobierz, plaintext 
class Model_Articles extends Db{
 
	public function get_articles(){
 
	}
	public function delete_articles(){
 
	}
   //i tak dalej
 
}
[PHP] pobierz, plaintext 

- i to klasa db martwi się o to, jakiego użyć sterownika bazy danych i nawiązuje połączenie z bazą danych, nie wyobrażam sobie przekazywać za każdym razem połączenia w konstruktorze, bo nie po to używam jakiegoś algorytmu czy wzorca, by komplikować sobie życie. Skoro dziedziczenie złe, singleton zły, registry złe (a i tak każdy tego używa) to co zostaje? Te rzeczy powstały, by aplikacja była wygodna i nieprzekombinowana.

Wiesz czym jest w ogóle PDO? Raczej mało prawdopodobne by chciał go zamienić... zresztą jeżeli już się na takie coś zdecyduje to akurat tamten fragment kodu będzie jego najmniejszym zmartwieniem.Utworzenie wielu obiektów Model_Artickes czy podobnych (dziedziczących po Db) będzie skutkowało wielokrotnym wywołaniem konstruktora z Db co zapewne nawiąże wiele połączeń z bazą danych.Czyli jednak uważasz, że telefonistka to jest coś co jest rozszerzeniem telefonu?

Dziedziczenie jest złe jeżeli jest źle używane - tak jak tutaj.
Singleton też jest zły tylko wtedy, gdy jest źle używany (zwróć uwagę, że celem jego stosowania powinno być zagwarantowanie dokładnie jednej instancji danej klasy, a nie globalnego dostępu do owej instancji)
A to to akurat - w kontekście do jakiego się zapewne odnosisz - jest złe, gdyż całe modelowanie aplikacji idzie się @#$@#%^* dzięki temu - ja (i nie tylko) nie używam
Nauczenie się doboru odpowiednich narzędzi i technik do danych zadań.
Nie będę się sprzeczał - ale wygodne są tylko wtedy, gdy są poprawnie użyte. A o przypadkach w projektach z serii "hello world" gdzie global, @, eval itp są fajne to się tutaj nie wypowiadam - tam, to wszystko jest fajne.

- a jak wywołujesz proste zapytania w kontrolerze, co ja robię tak:

[PHP] pobierz, plaintext 
$a = new model_articles;
$a->delete('id='.$this->request->id);
$b = new model_articles_comments;
$b->delete('id_article='.$this->request->id);
[PHP] pobierz, plaintext 

- tworzyć metodę delete dla każdego modelu? Dlaczego dziedziczenie poszczególnych tabel po obiekcie baza_danych w takim przypadku jest złe? Jest to niezgodne z teorią czy niesie w sobie jakieś inne, ukryte zagrożenia? Czy po prostu niepraktyczne, bo ten aspekt akurat interesuje mnie najbardziej, by kod był prosty i przejrzysty.

Zapytania w kontrolerze? A co ma Kontroler do zapytań? Tuż to działa Modelu, którego sposób działania jest transparentny dla Kontrolera.Ponieważ w Twoim przypadku ten obiekt "baza danych" to obiekt na kształt PDO - odpowiedzialny tylko za wywoływanie/obsługę samych zapytań. Konkretna tabela nie jest rozszerzeniem czegoś takiego, ona z tego korzysta.To i to. Kod jest nielogiczny, wcale jakiś prosty nie jest (po co delete('id=123') zamiast delete(123), po co usuwanie komentarzy z poziomu aplikacji skoro tym może zająć się sama baza? A jeżeli ona tego nie może to powinna to zrobić metoda delete obiektu model_articles), a w dodatku w przypadku gdybyś go kiedyś jakoś rozbudował czy zaczął pracować w grupie nad nim zaraz by powychodziło to jaki jest on nieelastyczny i mało funkcjonalny.Kod nie ma być zawsze prosty i przejrzysty... ma być odpowiednio elastyczny i łatwy w końcowym użyciu. Oczywiście aspekt jego rozbudowy jest nie mniej ważny.

dziedziczenie po bazie danych to zły pomysł.

jest lepsza metoda, tworzysz sobie klasę będącą przodkiem dla wszystkich Twoich modeli które będą używały bazy danych i w jego konstruktorze tworzysz sobie instancję klasy obsługi bazy danych z mniej więcej takim konstruktorem:


(przykłąd z Kohana framework)

potem Twoje modele dziedziczą po tym przodku i nie musisz się martwić o to że za każdym razem musisz ładować bazę danych. Jak Ci jest zbędna db, lub chcesz coś innego Tworzysz innego przodka z obsługą xml, txt, nosql itd.

PS. polecam ten framework (Kohana) do nauki OOP, podglądając jak oni to zrobili powinieneś szybko załapać idee OOP i MVC