Uwagi, pytania zwiazane zwiazane z artykulem Nalfeina "Kurs OO" prosze pisać w tym temacie.

cudo. Pomimo póżnej pory musiałem przeczytać i już czekam na kolejne odcinki z tej serii.

piękny przykład ale zawiera błędy.
php 5.0.0b4 nie idzie.
Nigdzie w manualu nie znalazłem o tym:
function pobierz(DaneUzytkownika $szukamy)
i z przykładu wynika że nie działa.

Bora, czy zdajesz sobie sprawę, że to nie jest tutorial, tylko kurs?
Nie wkleja się bezmyślnie kodum, tylko go analizuje. To jest podstawowa róźnica.

Po doczytaniu w Zend2-engne okazuje sie że skłądnia jest dobra.
sorrka. Mino to w kodzie są literówki.

Mi bardzo się przyda ten kurs bede się na nim opierał, bo widze że wkoncu jest jeden rzetelny serwis z dobrymi artykułami a nie powtarzajacymi sie nudnymi,dziurawymi, skryptami.... :wink:

Witajcie. Cieszę się, że już na tym etapie, po kilku dniach publicznego udostępnienia pojawiło się tyle pozytywnych opinii, to tylko mobilizuje do działania Kod piszę już pod działajace PHP5, wg. tego co ludzie pisali o jego możliwościach, to było zresztą tylko wprowadzenie, mające zachęcić do uczenia się obiektówki, przejścia z PHP4 do PHP5 itd. Wdalszych częściach będę zaznaczał co działa w PHP5, a co w PHP4 - może zrobię osobny rozdział o różnicach. Może też powstanie kurs OO dla znających C++ czy Javę, taka prosta specyfikacja składni dla potrafiących już pisać obiektowo, jednak nie mających jeszcze do czynienia z php, napisana mniej "epickim" stylem, a więc i bardziej zwięzła.

Właśnie otrzymalem od scannera wersję z poprawionymi literówkami i nie pozostaje mi nic innego jak dopisać kolejny odcinek. Oczekujcie go w ciągu tygodnia, góra dwóch.

Pozdrowienia dla wszystkich moich czytelników
Nalf

Ten artykuł jest super wczoraj do 3 siedziałem żeby go przeczytać i udało mi sie ale pozostal pewien niedosyt bo urywa sie on tak jakby w polowie a ja chce wiecej ... juz nie moge sie doczekac kolejnych czesci ...

Dzisiaj rozszerzony został II rozdział kursu. Miłej lektury.

mi sie nie podoba w tym kursie to, ze jest to niby wstep dla chcących zaczac programowac obiektowo, ale jest troche chaotycznie. momentami autor zwraca sie jakby czytelnik znal juz jak to wyglada w php4 i mowi tylko o zmianach jakie zeszly w php5, a potem tlumaczy jak laikowi progr.obiekt. w ogole. ogolnie po prostu mozna sie nieco pogubic. nie wiem wlasciwie dla kogo to jest artykul... dla przechodzacych z php4 na php5 czy tez dla poczatkujacych w obiektowym w ogole? teoretycznie dla tych i dla tych, a praktycznie wychodzi chaos. takie jest moje zdanie jako poczatkujacego (obiektowe tylko troche liznalem w c++)

Chodzi konkretnie o jakiś fragment czy tylko o ten fragment końcowy, który dopisałem? Tamten przeredaguję go i przeniosę go do innego rozdziału. Co do formuły - dla początkujących piszących pod PHP5. Dla przenoszących się z PHP4 do PHP5 będzie osobny rozdział. Chaosu chciałem uniknąć, jednak także zachować wmiarę luźny styl, aby się to łatwo pochłaniało. Wskaż, gdzie wieje chaosem, a zobaczę co się da z tym zrobić.

Zgadzam się, że początek jest bardzo chaotyczny. We wstępie umieszczono zbyt wiele informacji, a wystarczyło tylko krótko i ogólnie wyjaśnić na czym polego oop. W przeciwieństwie do pierwszego rozdział drugi jest SUPER!

@nalfein, oto moje uwagi. najlepiej najpierw opisac podstawy prog obiektowego w php4, a potem zmiany jakie sie dokonaly w php5. najlepiej chyba po prostu na samym poczatku wytlumaczyc ogolnie co to klasa, jaka jej struktura, co to konstruktor, destruktor, metoda. jaka roznica miedzy klasa a obiektem, sposob wywolywania, takze funkcji, dostep do zmiennych. potem dziedziczenie... i juz cale podstawy zrobione. wszystko jasne, napisane bardzo prostym jezykiem, z samymi bardzo prostymi przykladami typu sumowanie liczb...

Ok, przemyślę to. Rozdział pierwszy zostaje jako "pokaz możliwości"

Miesiąc minął już prawie od publikacji, więc nie wiem jakie zmiany zaszły w artykule, jednak dopiero co przeczytałem ten text i mam parę pytań "technicznych". Programuję w C++ od ok. 2 lat więc mam już jako takie pojęcie o OO, jednak php niektóre rzeczy traktuje odmiennie, więc prosiłbym o wyjaśnienie:

Rozdział 1 -> Rozwiązania obiektowe

[php:1:5c8d52847b]<?php
class DaneUzytkownika
{
// nasza wlasciwosc, chroniona przed dostepem z zewnatrz
protected $dane = array();

function __construct($dane = array())
{
if (is_array($dane))
$this->dane = $dane;
else if ($dane instanceof DaneUzytkownika)
$this->dane = $dane->pobierzJakoTablica());
}

...

?>[/php:1:5c8d52847b]


Czy pole klasy $dane i wartość przekazywana do konstruktora $dane to ta sama zmienna? Jeżeli nie, to dla przejrzystości kodu można by zastosować inną nazwę żeby się nawzajem nie myliły. W C++ nazywa się to przesłanianiem zmiennej, czy jakoś tak, ale w php jestem nowicjuszem więc się pytam.

pzdr.

$this->dane to odwołanie do protected $dane = array();

Natomiast $dane pojawiające się jako paramter konstruktora to osobna zmienna widoczna tylko wewnątrz tej metody. Czyli podobnie jak w C, jest to inna zmienna.
Jednak w tym przypadku, z uwagi na to, że jest ona niemal odrazu 'przepisywana' do odpowiedniego atrybutu, więc użycie tej samej nazwy nie powinno być kłopotliwe.

Dzieje się tak jeszcze z jednego powodu. W php wewnątrz klasy nie można się odwołać do atrybutów klasy tylko tak: $this->atrybut. Nie ma czegoś takiego, jak przezroczysty dostęp do atrybutów, z którym się spotykamy w C++, więc nie ma też większego ryzyka, że programista się pomyli...

Dzięki za to wyjaśnienie, jednak jeszcze jednej rzeczy nie rozumiem, dalej w obrębie konstruktora 8)

W linii 7, w parametrze konstruktora, do zmiennej $dane przypisywana jest tablica: $dane = array()

Kiedy wykona się instrukcja warunkowa: else if ($dane instanceof DaneUzytkownika), bo przecież już na wstępie $dane jest inicjowana tablicą?

zapis [php:1:8687471add]<?php
function nazwa_funckji( $paramtetr = array() )
?>[/php:1:8687471add]
oznacza, że $parametr nie jest wymagany, czyli w przypadku wywołania
[php:1:8687471add]<?php
nazwa_funckji();
?>[/php:1:8687471add]
przyjmie on podaną wartość (w tym przypadku stanie się pustą tablicą)

Jeśli jednak wywołamy tą funkcję z parametrem, np. [php:1:8687471add]<?php
nazwa_funckji( 'ala ma kota' );
?>[/php:1:8687471add]
to automatycznie $parametr przyjmie wartość "ala ma kota" która to jest zwykłym stringiem.

Dlatego też, z uwagi na to, że php pozwala na takie 'podmienianie' typów zmiennych, przydatne jest sprawdzanie typu danej zmiennej już w kodzie.

Czylim mógłbym napisać konstruktor bez wartości domyślnej, np:
[php:1:4a4bde714a]<?php
class DaneUzytkownika
{
// nasza wlasciwosc, chroniona przed dostepem z zewnatrz
protected $dane = array();

function __construct($dane)
{
if(is_array($dane))
$this->dane = $dane;
else if($dane instanceof DaneUzytkownika)
$this->dane = $dane->pobierzJakoTablica();
else
$this->dane = array();
}

...

}
?>[/php:1:4a4bde714a]

i ten kod będzie działał tak samo jak kod napisany przez Nalf'a?

PS1. Wiem że ten kod jest mniej "elegancki" - pytam się tylko czysto teoretycznie, być może Nalf uwzględni te dywagacje w kursie dla ludków przechodzących z C++ na php

PS2. Jednak teraz widzę, że ostatnia linia jest zbędna, ponieważ pole chronione klasy $dane jest na starcie inicjowane tablicą.

Witam
Dla mnie ten artykuł jest bardzo przydatny, jeden z niewielu traktujących o OO jako takim a nie tylko o konstruowaniu klas i uzywaniu metod :|
Niestety.. pozostaje niedosyt...
Najbardziej zaintrygował mnie fragment rodziału I - Rozwiązanie obiektowe... niestety do tej pory byłem kimś kto robił to co tam napisałeś gdzieś - wrzucałem funkcje do worka zwanego klasą i instatnowałem to :| na szczęście (dla mnie) moje sumienie działało prawidłowo i od zawsze wiedziałem ze to jest dalekie od prawidłowości dlatego wciąż poszukiwałem "ścieszki obiektowej"
Mój problem polega na tym, ze nie potrafię mysleć o kodzie obiektowo, wiez ze jest to problem analizy i modelowania danych przede wszystkim, ale szukałem w Twoim artykule wskazówek jak konstrułować klasy aby były elastyczne, jak dziwdziczyć i co. Jak wydzielać klasy abstrakcyjne... po prostu podstaw obiektowości.
Liczę bardzo na to, że będziesz kontynuował ten artykuł.
Jeszcze przydał by się jakiś rozdział o optymalizacji i wydajności.
Wiadomo, że php różni się od innych języków środowiskiem pracy. Każde wywołanie skryptu wiąże sie z nowymi odwołaniami do bd i instancjami obiektów. Na ile sobie można pozwolic, w jakim kierunku budować obiekty aby nie obciążały niepotrzebnie bd i systemu kolejnymi wystąpeniami. O tym chciał bym przeczytać.
Dzięki za artykuł.

Mnie męczy jeszcze jedna sprawa. Jak najlepiej przekazywać obiekty?
Mam np. obiekt bazy danych, smarty i jeszcze kilka że tak powiem klas głównych

[PHP] pobierz, plaintext 
<?php
$db = new db();
$smarty = new Smarty();
...
 
?>
[PHP] pobierz, plaintext 

I teraz mam kolejną klasę, która ma używać dokładnie tych obiektów (nie kopii). I właśnie, jaki jest najlepszy sposób, aby przekazywać te obiekty? Mi się nasuwają 2 różne, ale oba wymagają przypisania $this->db = $db; i odwoływania się do za pośrednictwem $this->...

[PHP] pobierz, plaintext 
<?php
 
class foo{
    function foo(){
        global $db;
        $this->db=$db;
        $this->db->fetch();
    }
}
// i drugie
class foo{
    function foo($db){
        $this->db=$db;
        $this->db->fetch();
    }
}
 
?>
[PHP] pobierz, plaintext 

Da się to jakoś elegancko rozwiązać?

mozesz zrobic klase ktora bedzie 'magazynem' obiektow, do ktorego bedziesz sie odwolywal, magazyn bedzie mial za zdanie sprawdzic czy instancja obiektu juz jest stworzona, jesli nie to twozy i oddaje referencje, a jesli juz jest to tylko oddaje referencje.
innym sposobem jest robienie, podczas tworzenia, metod statycznych ktore sa odpowiedzialne za tworzenie instancji. Metoda chyba wynkonanla jest tylko przy php w wersji 5

Ta metoda to wzorzec projektowy singleton, i mozna go zaimplementowac takze w php 4 (choc dzieki wlasciwoscia statycznym w php 5 jej implementacja jest wygodniejsza i bezpieczniejsza). Przyklad implementacji w php 4:

[PHP] pobierz, plaintext 
<?php
	class Templates {
		function &getInstance() {
			static $instance = null;
 
			if ($instance == null) {
				$instance = new Templates;
			}
 
			return $instance;
		}
	}
?>
[PHP] pobierz, plaintext 

Tak by to moglo wygladac w php 5:

[PHP] pobierz, plaintext 
<?php
	class Templates {
		private static $instance = null;		 
 
		// prywatny konstruktor!
		private __construct() {
		}
 
		public static function getInstance() {
			if (self::$instance == null) {
				self::$instance = new Templates;
			}
 
			return self::$instance;
		}
	}
?>
[PHP] pobierz, plaintext 

Singleton pozwala nie tylko na posiadanie dostepnej wszedzie instancji obiektu, ale zabezpiecza także przed powstaniem więcej niż jednej instancji danego obiektu. W obu przypadkach przekazanie referencji do naszego obiektu wygląda tak:

[PHP] pobierz, plaintext 
<?php 
	// w przypadku php 4 nalezy jeszcze dodac po znaku rownosci &, w celu zmuszenia php do przekazania referencji (a nie stworzenia kopii). php 5 robi to domyslnie dla obiektow.	 
	$tpl = Templates::getInsance();
?>
[PHP] pobierz, plaintext 

Dzięki za odpowiedzi.
Kiedyś czytałem o wzorcach projektowych, ale przeczytać, a widzieć gdzie jakiego wzorca użyć to co innego... Chyba jednak użyję pierwszej metody ze względu na kompatybilność zrówno z php 4 jak i 5.
Sposób z magazynem obiektów nie do końca mi się podoba...
Cudi, jest mały błąd - brakuje function.

[PHP] pobierz, plaintext 
<?php
 
		// prywatny konstruktor!
		private function __construct() {
		}
 
?>
[PHP] pobierz, plaintext 

Dopiero teraz przejrzałem ten kurs, dlatego jestem może trochę nie w temacie Chciałem tylko powiedzieć, że rozdział I może przerazić początkujacego programistę.

Autor zaczął trochę z grubej rury, tak jakby od tyłu. Osobiście jestem zwolennikiem uczenia się czegokolwiek (w tym również OO) od podstaw i prostych przykładów z życia wziętych. Przykłady zamieszczone w tym kursie zawierają zbyt dużo rzeczy - zapytania sql, includowanie, pętle, smarty. To zaciemnia ideę OO, bo czytelnik może mieć dylemat, na czym ma się skupić. W dodatku częstą praktyką uczących się (znam to ze swojego i nie tylko swojego doświadczenia) jest przepisywanie przykładów toćka w toćkę, więc żeby te z kursu zadziałały, trzeba zrobić wiele rzeczy dookoła.

Czy nie lepiej byłoby podawać prostsze przykłady, chociażby banalny i oklepany, ale uniwersalny i piękny przykład klasy "Figura", jej pochodnych "Trójkąt", "Kwadrat", "Koło" z parametrami "pozycjaXY", "typFigury", metodami "podajTyp", "przesunDoGory" i metodami wirtualnymi np. "obliczPole", "narysuj" itp? W definicji oczywiście nie trzeba by podawać całego kodu na obliczenie pola czy procedury rysującej figurę, tylko opatrzyć ją odpowiednim komentarzem typu "tutaj idzie procedura rysująca".

Wiele podręczników do programowania pisanych nawet przez tzw. "doświadczonych dydaktyków" zawiera zbyt dużo informacji i dlatego mogą być nieczytelne dla ludzi dopiero zaznajamiających się z danym tematem.

Nie twierdzę, że podawanie zbyt złożonych przykładów uniemożliwia poznanie tematu, ale może zająć dużo więcej czasu A ponieważ OO jest w modzie, więc być może nawet początkujący programiści chcieliby się zaznajomić z tym tematem przy okazji uczenia się php. A przecież warto