Witam, chciałbym nauczyć się programować obiektowo. Strukturalnie już jako tako umiem, potrafie napisać jakiegoś małego CMS ...
Czytałem dziś pół dnia na temat obiektówki ale jakoś i tak mało zrozumiałem... Teoretycznie chyba rozumiem, ale praktycznie nie potrafie tego zastosować.
Więc po całym dniu czytania spróbowałem coś napisać i napisałem skrypty wyświetlający wiadomości z funkcją ograniczania wyników. No i udało się, pełni swoją funkcje ...
Lecz naprawde nie wiem czy On jest poprawnie napisany obiektowo, może wy sprawdzicie i mnie `nasterujecie` na prawidłową droge A oto kod:

[PHP] pobierz, plaintext 
<?php
 
	class Show
		{
			function __construct($where, $number)
				{
					$this -> where = $where;
					$this -> number = $number;
					if(!isset($_GET['page'])) { $this -> page = 0; }
					if(isset($_GET['page'])) { $this -> page = $_GET['page']; }	
					$this -> result = $this -> number * $this -> page;
				}
 
			function show()
				{
					$pdo = new PDO('mysql:host=localhost;dbname=BAZA', 'LOGIN', '');
					$request = $pdo -> query('SELECT * FROM '.$this -> where.' ORDER BY id DESC LIMIT '.$this -> result.','.$this -> number.'');
 
					while($result = $request -> fetch())
						{
							print $result['subject']."<br/>";
						}
 
					unset($request);
				}
 
			function pages()
				{
					$pdo = new PDO('mysql:host=localhost;dbname=BAZA', 'LOGIN', '');
					$request = $pdo -> query('SELECT * FROM '.$this -> where.'');
 
					$number_of_rows = $request -> rowCount();
					$number_of_pages = ceil($number_of_rows/$this -> number);
 
					for ($i = 0; $i < $number_of_pages; $i++)
						{
						       echo '<a style="margin: 5px;" href="?page='.$i.'">'.$i.'</a>';
					                }
 
					unset($request);							
				}
		}
 
?>
[PHP] pobierz, plaintext 

Mam właściwie jeszcze jedno pytanie, jak zaopatrzyć to w `skórki` ? Strukturalnie napisałem sobie skrypt który do tablicy pobiera plik i funkcją str_replace podmieniam treść. Sprawdza się to dobrze, ale obiektowo to raczej nie jest poprawnie. Pozdrawiam

Poczytaj o mvc, zreszta prosty szablon moze byc i parsowany, tzn masz pole %Autor% podpinasz pod nie autora.

Kod pisany chyba pod php4 bo nie wiedze zadnych zdefiniowanych dostepow do metod.

Po 2 masz pola where i number ale nigdzie ich nie deklarujesz.

A po co w każdej metodzie tworzysz obiekt PDO Można to w konstruktorze zrobić i odwoływać się w każdej innej metodzie. Nie obawiaj się konstrukcji typu

[PHP] pobierz, plaintext 
$this->pdo->query( 'SELECT ... LIMIT 1' );
[PHP] pobierz, plaintext 

Raz masz print raz echo zdecyduj się na jedno.
W klasie nic nie powinno być wyświetlane metody powinny coś zwracać przez return.

[PHP] pobierz, plaintext 
if(![url="http://www.php.net/isset"]isset[/url]($_GET['page'])) { $this -> page = 0; }				if([url="http://www.php.net/isset"]isset[/url]($_GET['page'])) { $this -> page = $_GET['page']; }	
[PHP] pobierz, plaintext 

To też możesz wogóle poza klasę wyrzucić i odwołując się do konkretnej metody podać jako parametr numer strony.
No i jak kolega wcześniej napisał poziomy dostępu do metod i zmiennych ( zmiennych nie ma więc w tym przypadku tylko metod ).

No juz konstruktor wczoraj rozgryzłem i zrobiłem tak jak mówisz W każdej metodzie odwołuje się do konstruktora i dodałem jeszcze destruktor który niby ma mnie rozłączać z bazą danych.
Tylko nie rozumiem tych `poziomów dostępu do metod i zmiennych`. Ide teraz do pracy, jezeli komus bedzie sie chcialo moze wyjasnic:)
Ale to tylko za odrobiną chęci, jeżeli nie to poczytam sobie póżniej jakieś `kursy`

A jeszcze mam jedno pytanie bo w konstruktorze i destruktorze dałem tak:

[PHP] pobierz, plaintext 
function __construct()
     {
          $this -> pdo = $pdo = new PDO(DANE);
     }
function __destruct()
     {
          $this -> pdo = $pdo -> null;
     }
[PHP] pobierz, plaintext 

Czy to jest prawidłowe rozwiązanie ? Wyciągnałem to z jakiś kursów Wszystko działa, tylko nie mam pewności co do funkcji destruct ... Pozdrawiam

Poczytaj o public,protected i private.

PDO nie znam wiec nie wiem ale ogolnie destruktor do rozlaczenia nie jest potrzebny bo baza sama powinna konczyc sesje polaczenia.

Dobrym nawykiem świadczącym o wiedzy jest kończenie połączenia samemu.

Ja tak robie,robilem i bede robic jednak nie raz na forum gdy podawalem kod powiedziano mi ze jest to niepotrzebne

Zawsze znajdzie się ktoś, kto w danej kwestii będzie miał odmienne zdanie

Ja osobiście uważam, że jeśli tworzysz konstruktor, to powinieneś od razu stworzyć destruktor. Jakoś nie mam zaufania do wbudowanych rozwiązań określonych języków, które są podobne do działaniu do Garbage Collectorów w Javie. Ktoś, kto pracował w C++ i przydzielał dynamicznie pamięć wie o czym mówię. Pamięć może szybko "wycieknąć". To nie jest kwestia "może, ale nie musi być", tylko swego rodzaju niechlujstwa, choć może bardziej by pasowało "nadmiernego zaufania do języka". Większość dobrych nawyków programowania C++ potrafił mnie nauczyć, bo jest pod tym względem niezbyt litościwy Po przejściu "podstaw szkoły C++" człowiek zaczyna nawet w bardzo przyjaznych językach zwracać uwagę na drobiazgi, które inne języki, takie jak PHP akceptują i wyręczają nas w tym częściowo. Choćby w PHP używanie mysql_close() czy mysql_free_result() są takimi "archaizmami", które wiele osób odpuszcza, bo wie, że i tak zasoby będą zwrócone po wykonaniu skryptu. Szkoda tylko, że część osób nie wie, że owe rozwiązania też mają czasem problemy i pamiętam jak na studiach się dziwiłem błędami pisząc w Javie, gdy po zakończeniu miałem błędy. GC Javowski po prostu miał problem ze zwróceniem do systemu dynamicznie przydzielonej pamięci. Od tamtego czasu jego (GC) kod poprawili i coraz rzadziej to się ludziom zdarza, ale zapewne wciąż nie jest rozwiązane idealnie. Stąd to programista powinien dbać o pamięć i nie zdawać się na wbudowane narzędzia.

Osoby tworzące kod bez dbania o destruktory same proszą się o problemy w przyszłości. Nie po to owe metody powstały by były sztuką dla sztuki. Są w określonym celu i należy o nich pamiętać. Oczywiście zwracanie do systemu pamięci rezerwowanej przez typy proste jest już przegięciem w drugą stronę. Wszystko z głową należy robić.

Jednym zdaniem: "Jeśli gdzieś definiujesz w programowaniu obiektowym konstruktor, destruktor też od razu napisz, a unikniesz problemow na przyszłość."

@bottom: (To Mike): Bo kilka lat w poprawianiu kodu GC w Javie zrobiło swoje Gdy na studiach pisałem w nim kod to gubił z pamięci nie kB, ale MB pamięci bardzo szybko, a soft był odpalany nie przez minutę ale chodził nieraz godzinami odpalając się w wielu wątkach Pamięc tak dostawała w czapę, że trochę pochodził i się wysypywał bez ostrzeżeń GC tylko częściowo sobie z tym problemem radził bo usuwał zmienne obiektu dla niego widoczne, ale "gubił", tę część pamięci którą gdzieś mu dynamicznie przydzielałem Czasem ją przechwycił, czasem nie i stąd trudno się z początku było połapać co jest nie tak. Stąd teraz byle pierdółkami się przejmuję, by takiego szukania w pozornie bezbłędnym kodzie unikać. Bo przecież pod względem języka jest on poprawny, co tylko bardziej irytuje przy ego wyłapywaniu. Wiesz, że coś nie działa, ale nie można ściśle określić miejsca problemu na pierwszy rzut oka.

@bottom: (To darko): Postaram się takie zwięzłe streszczenia pisać, choć nie zawsze jest to możliwe z racji opisywanego zagadnienia czy problemu.

Ja tam w Javie nie mam destruktorów. I jakoś specjalnie mnie to nie martwi.

OT, sorry
@thek: ja chyba będę czytał tylko to Twoje, niech to będzie standardem, że na końcu będzie takie podsumowanie całego posta w jednym zdaniu

Witam, dzis wieczorem posiedzialem, poczytalem i postaralem sie zlepic skrypt do wyciagania danych z bazy a nastepnie ich parsowania do `motywu`
Lecz nie wiem czy zrobilem to dobrze. Przyjzyjcie sie zwracaniu wynikow Jezeli macie inne pomysly, linki co kolwiek co moze mi z tym pomoc to chetnie bym prosil.
Czy ten skrypt jest mniej-wiecej napisany obiektowo ? (To moj pierwszy skrypt w obiektowce, troche ciezko mi sie przestawic z kodu strukturalnego ale z tym walcze:) )
Pozdrawiam

[PHP] pobierz, plaintext 
	class Show
		{
			public $select;
			private $select_from;
			private $template;
 
			public function __construct($select_from, $template)
				{
					try
						{
							$this -> pdo = $pdo = new PDO('mysql:host=localhost;dbname=, , '');
						}
					catch(PDOException $e)
					   {
					      echo Blad Polaczenia: ' . $e->getMessage();
					   }
 
					$this -> from = $select_from;
					$this -> template = $template;
					$this -> select = $select;
				}			
 
			public function __destruct()
				{
					$this -> pdo -> null;
				}
 
			public function getcontent()
				{
					$pq = count($this->select);
 
					for($i = 0; $i < $pq; $i++)
						{
							if($i != $pq-1)
								{
									$query .= $this->select[$i].",";
								}
							if($i == $pq-1)
								{
									$query .= $this->select[$i];
								}
						}
 
					$request = $this -> pdo -> query("SELECT $query FROM $this->from");
					$number_of_rows = $request -> rowCount();
 
					for ($i = 0; $i < $number_of_rows; $i++)
						{
							$result = $request -> fetch(PDO::FETCH_ASSOC);
							for($x = 0; $x < $pq; $x++)
								{
									$after[$x] = $result[$this->select[$x]];
									$before[$x] = strtoupper('['.$this->select[$x].']');
								}
 
							$return .= show::tpl_parse($before, $after, $this -> template);
						}	
					unset($request);
					return $return;
 
				}
 
			static function tpl_parse($before, $after, $tpl)
				{
					$file = file("templates/".$tpl);					
					$count = count($file);
					for($i = 0; $i < $count; $i++)
						{
							for($x = 0; $x < count($before); $x++)
								{
									$file[$i] = str_replace($before[$x], $after[$x], $file[$i]);	
								}
						$return .= $file[$i];								
						}
					return $return;	
				}
		}
 
$news = new Show("news", "news.tpl.html");
$news -> select = array("subject", "content");
print $news -> getcontent();
 
 
[PHP] pobierz, plaintext 

Nie jest zle ale jak dla mnie na twoim miejscu zmienilbym 3 rzeczy wedlug mojego punktu widzenia.

-Dodal setter na pole select

-Zmienilbym dostepy do wszystkich pol na protected

-Fukcji tpl_parse() dal dostep protected, bo jak narazie jest public.

Przepraszam za OT ale cała ta dyskusja o "poprawności manualnego wywoływania destruktora" mnie zmusza do zajęcia stanowiska

Otóż proszę Państwa każdy obiekt w PHP ma destruktor, nawet jeśli go nie zadeklarujemy. I jest on automatycznie wywoływany przez parser PHP na końcu skryptu. Więc o ile nie chcemy zrobić czegoś dodatkowego, np zapisać finalnej struktury obiektu w pliku, przed zniszczeniem instancji to jego używanie jest nieuzasadnione. Wręcz kiedyś widziałem test który wykazywał spowolnienie działania aplikacji przy użyciu manualnych destruktorów.

Co do zamykania połączenia z bazą danych to robiąc to manualnie możemy co najwyżej spowolnić działanie aplikacji. Dopuszczalne to jest w momencie gdy korzystamy na stronie z bazy sporadycznie ale w normalnej sytuacji, gdzie każdy element strony wyciąga dane z bazy jest to wręcz niedopuszczalne.

Temat by można wydzielić do dyskusji bo jest w miarę ciekawy;) Jeszcze raz sorry za OT.

To i ja znów zajmę stanowisko... Nie pisano tu o "manualnym wywołaniu destruktora" (a przynajmniej nie ja o tym pisałem) tylko o jego zdefiniowaniu w kodzie obiektu To, że destruktor jest wywoływany zawsze przy niszczeniu obiektu jest wiadome i nawet jeśli obiekt nie posiada destruktora to pamięć związana z polami obiektu jest zwalniana automatycznie. Tyle że jeśli majstrujesz coś z dynamicznym przydziałem to można się przejechać na cieknięciu pamięci.

Dlatego napisałem w " " Chodziło mi o właśnie definiowaniu destruktora w klasie. Sęk w tym że w PHP już w momencie tworzenia instancji obiektu parser PHP tworzy automatycznie metody konstruktora i destruktora. Więc one tam fizycznie są mimo że nie są zdefiniowane. Leak może powstać w dużych pętlach ale normalnie nie ma na to szans

Jeśli konstruktor polega jedynie na kombinowaniu z typami wbudowanymi czy prostymi obiektami to rzeczywiście jest to bezsensowne i mija się z celem tworzenie destruktorów. Jeśli jednak zaczyna się porządnie grzebać to przy większym obciążeniu czy choćby dużej ilości działań na obiektach, wielu odwiedzających, te "zgubione" skrawki pamięci się szybko namnażają i w efekcie wyczerpują zasoby dostępne dla strony na hostingu. Na szczęście "zarżynaczami" bawię się tylko na lokalu, ale niczym niezwykłym dla mnie jest choćby to, że wygenerowany plik ma ponad 1MB jako czysty html i potrafi kompowi zeżreć 1.5GB pamięci będąc pisany najbardziej optymalnie jak się tylko da.