Tworząc interfejs używamy słowa abstract przy definicji metod.

Po co używa się tego słowa przy definicji klas (lub funkcji - w przypadku gdy nie jest to interfejs) ?
W jakim celu tworzyć abstrackyjne klasy?

W przeciwieństwie do interfejsów w klasach abstrakcyjnych masz ciało metod, czyli częściowe zaimplementowanie interfejsu, możesz wymuszać obecność metod w klasach jak i iniemożliwić nadpisanie innej itp.

Fajnym przykładem może być obsługa akcji w frameworkach np:

[PHP] pobierz, plaintext 
<?php
abstract class SzablonAkcji {
 
protected $przywileje = array('public');
 
abstract public function akcjaAlternatywna(); // wymuszamy utworzenie tej metody w klasach dziedziczących
 
final function OdpalAkcje() // w klasach dziedziczących nie mozemy nadpisac tej metody
{
  $action = new HttpRequest->get('action');
  $action = $this->$action . '()';
 
  if(method_exists($action, $this))
	$this->action;
  else
	$this->akcjaAlternatywna();
}
}?>
[PHP] pobierz, plaintext 

Stworzony został prosty szkielet do obsługi akcji, czyli wywoływania odpowiednich metod na podstawie urla, aby wyświetlić przykładowo newsy musimy utworzyć klasa WyswietlNewsy która będzie dziedziczyć nasz SzablonAkcji.

[PHP] pobierz, plaintext 
<?php
 
class WyswietlNewsy extends SzablonAkcji {
 
protected $przywileje('admin');
 
public function AkcjaAlternatywna()
{
  echo 'Błąd obsługi akcji';
}
 
public function WyswietlNewsy()
{
  // wyswietlanie newsow
}
 
}
?>
[PHP] pobierz, plaintext 

Pisałem z palca więc mogą byc błędy, ale myślę że teraz wiesz miej więcej jak to działa

Heh wytlumaczone dobrze, ale dziwnie. J4r0d: pojęcie interfejsu znasz prawda? więc wyobraź sobie teraz ze masz 10 klas, ktore dziedzicza ten inerfejs (niech to bedzie metoda foo()) i dla tych klas metoda foo() wyglda tak samo, gdybys uzywal tylko interfesjow musail bys napisac 10 razy ten sam kod, a tak tworzysz sobie klase abstrakcyjna i ona zawiera juz cale cialo metody foo(). Dodatkowo powiem, ze nie mozesz utworzyc instacji ani odwolac sie do pola klasy abstrakcyjnej - czyli sama w sobie jest bezuzyteczna, uzywamy jej jedynnie jako rodzica innej klasy. Btw. Ten temat byl juz poruszany....

Klasy abstrakcyjne nie są wygodnym narzędziem do definiowania interfejsów. Sprawdzają się, kiedy musisz wymusić na potomkach określony zestaw metod, w którym część kodu metod jest wspólna. Ponadto przydają się przy takich wzorcach jak Template Method.


To nie jest do końca prawdą. Statyczne metody i właściwości klasy abstrakcyjnej nie zmieniają swojego zachowania. Dobrym nawykiem jest zadeklarowanie klasy jako abstrakcyjnej w przypadku, gdy cały jej interfejs tworzą metody statyczne i nie ma ona sensu w kontekście instancji. Dla przykładu przywołać można szczególną postać wzorca Registry.

[PHP] pobierz, plaintext 
<?php
abstract class Registry {
	public static function get($mKey) {
		//...
	}
 
	public static function set($mKey) {
		 //...
	 }
 
	public static function unset($mKey) {
		 //...
	 }
 
	public static function has($mKey) {
		 //...
	 }
 
	private static $registry = array();
}
?>
[PHP] pobierz, plaintext 

Mniej więcej łapie. Wychodzi na to, że lepiej używać klas abstrakcyjnych niż interfejsów. Dziwni mnie tylko, że w książce PHP5 zaaw. progr. nie ma (przynajmniej we wprowadzeniu do OOP) wzmianki o czymś takim jak final czy klasy anstrakcyjne.. :/

A skąd ten wniosek? To są narzędzia do dwóch podobnych, ale jednak różnych celów. Jeżeli chcesz zdefiniować tylko wymagany interfejs klasy, to używasz interfejsów. Jeżeli potrzebujesz utworzyć szkielet klasy, wtedy definiujesz klasę abstrakcyjną. Pamiętaj o jednej, znaczącej przewadze interfejsów. Możesz implementować wiele interfejsów w jednej klasie. Wielodziedziczenie w php nie istnieje.

W moich projektach na 10 (jeżeli nie więcej) interfejsów przypada mniej więcej jedna klasa abstrakcyjna.

Przecież zapis nie ma prawa bytu

[PHP] pobierz, plaintext 
<?php
class NazwaKlas implements Interfejs1, Interfejs2
{
 
}
?>
[PHP] pobierz, plaintext 

A sprawdziłeś czy to działa? Na mój gust działa... Tak się składa, że takie konstrukcje często się spotyka i od dawna jest mowa o tym, że w PHP5 można symulować wielodziedziczenie właśnie w taki sposób.

Mimo wszystko, najlepiej sprawdzić kod przed wysłaniem posta

lol strzelałem, wyssałem z palca

Po co klasa ma implementować dwa interfejsy? Nie potrafię sobie tego wyobrazić. Tzn. wyobrazić mogę tylko nie łapie sensu ..

Kilka tematów niżej jest przykładowa odpowiedź.

Sporo sensu to ma.
np. interfejsy:
1. save(), load()
2. setCommand(), executeCommand()

Juz masz 2 inetrfejsy - uważasz, że można te cztery metody umieścic w jednym intefejsie? Jak go nazwiesz?

Zgadza się. Dotąd rozumiem.



No dobra, czyli masz interfejs:

[PHP] pobierz, plaintext 
<?php
interface Metody {
	abstract function metoda1();
	abstract function metoda2();
}
?>
[PHP] pobierz, plaintext 

i klasę abstrakcyjną:

[PHP] pobierz, plaintext 
<?php
abstract class Abstrakcja {
	public function foo() {
	//... kod metody
	}
}
?>
[PHP] pobierz, plaintext 

1. I jak teraz utworzysz klasę, która implementuje interfejs Metody i jednocześnie dziedziczą po klasie Abstrakcja ?

2. Co dokładnie daje dodanie słowa static po słowie function?




Coś jest nie tak w metodzie OdpalAkcje(). Nie powinno być:

[PHP] pobierz, plaintext 
<?php
$action = new HttpRequest();
$action = action->get('action');
$action = $this->$action . '()';
?>
[PHP] pobierz, plaintext 

? Nie czaje ale to może dlatego, że to jest kawałek kodu.

W definicji interfejsów nie używamy słowa abstract. Interfejs zawsze definiuje tylko sposób wysłania komunikatu do obiektu.

Dziedzicząc można spokojnie implementować interfejsy.

[PHP] pobierz, plaintext 
<?php
class Konkretna extends Abstrakcyjna implements Interfejs1, Interfejs2, Interfejs3 {
	// Definicja klasy...
}
?>
[PHP] pobierz, plaintext 

Poczytaj phpedię... Metody statyczne operują na danych statycznych, czyli zajmujących stałe miejsce w pamięci i wywoływanych z kontekstu klasy, a nie obiektu. Metody i właściwości statyczne są dostępne bez konieczności tworzenia obiektów klasy.

Nie musisz tworzyć obiektu klasy aby wywołać metode, np singleton. Do metody statycznej odwołujesz się:
NazwaKlasy::metoda();



No ja w tym fragmencie popełniłem błąd, teraz jest dobrze.

Łapie. Mam jeszcze jedno pytanie. Żeby móc odwoływać się do klasy bez tworzenia obiektu, klasa musi być static.

Ostatnio widziałem gdzieś klasę statyczną, której kilka metod było statycznych a reszta nie. I co wtedy? Bez tworzenia obiektów możemy odwoływać się tylko do metod statycznych? A do pozostałych?

A do pozostałych nie - o to właśnie chodzi.Własnie we wzorcu singleton jest pokazana współpraca metod statycznych z niestatycznymi. Do metody statycznej możesz sie odwołac z kontekstu całej aplikacji - wystarczy, ze zadeklarowałeś wcześniej klasę. Jeśli stworzysz obiekt, to już musisz zacząć się o niego martwić tzn. brac poprawki np. na umiejscownienie obiektu

Pozdrawiam

Nie ma klas statycznych, moga byc tylko metody statyczne ktore wywolujesz:
NazwaKlasy::nazwaMetody()

Możesz to rozwinąć? Jakie umiejscowienie?

Faktycznie - trochę nieściśle się wyraziłem.

Chodzi o zwykły zasięg zmiennych. Jak stworzysz obiekt, to jest on przypisanu do jakiejś zmiennej. Od tego momentu musisz przekazywać jej referencję (lub kopię) do klas, funkcji, etc, jeśli chesz skorzystać z obiektu.

Pozdrawiam.

@J4r0d Wracajac jeszcze do pytania abstrakcyjne. Pamietasz swoje pytanie dotyczace przekazywania parametrow do metod w stylu addItem(Item $item).

Jasnym jest ze mozesz przekazac tutaj wszystkie instancje class ktore implementuja interfejs Item. Powiedzmy ze ten interfejs wymusza implementacje metody Pokaz() i Schowaj().
A co jesli 4 klasy ktorych chcesz uzywac maja taka sama metode Schowaj() ?
Bedziesz ja przepisywac od nowa ? No nie a tak to mozesz utworzyc abstrakcyjna klase Item w ktorej bedzie ta wpolna metoda w pelni zaimplementowana no i wymuszisz implementacje Pokaz().

Mozna by powiedziec ze po co mi abstrakcja skoro mozna dziedziczyc po zwyklej. No tak ale zwykla klasa nie wymusisz implementacji metody Pokaz() pozatym nie ma sensu tworzyc instancji klasy zawierajacej sama metode Schowaj() wiec tutaj przydaje sie abstrakcja. Nie dosc ze masz zapewnione to ze wszystkie kalsy beda mialy zaimplementowane wymagane przez Ciebie metody to jeszcze korzystasz z zalet dziedziczenia. Swoja droga to sie chyba nazywa polimorfizm to ze klasa wie od jakiej klasy pochodzi i mozna ja przekazac do metody jak wyzej.

Powoli łapie ale pewnie jeszcze nie raz będę Was gnębił. Jeszcze nie pisze obiektowo (kiedyś troche w C++) ale już dostrzegam zalety programowania obeiktowego. Chcę to zrozumieć a nie pisać dla pisania.



No właśnie można dziedziczyć. Skąd wiesz że tylko metoda Schowaj()? Może byłoby coś więcej Żartuje. Nie łąpie tylko jeszcze dlaczgo wszędzie wszystko wymuszać. WIem, że kilka osób może pisać różne części systemu, ale chyba powinni się najpierw zapoznać z projektem.

Mam jeszcze takie pytania

1. Interfejs zawiera tylko deklaracje metod. Metody te mogą być public (dostępne ze wsząd i dla każdego), private (dostępne tylko dla klasy je zawierającej, niedostępne dla klas które dziedziczą) i protected (dostępne tylko dla klas dziedziczących)? Interfejs gwarantuje, że dana metoda zostanie zaimplementowana w klasie, które implementuje interfejs. To, że klasa interpretuje interfejs nie oznacza, że nie może mieć innych metod?

2. Klasy abstrakcyjne pozwalają na wymuszanie implementacji metod w klasach dziedziczących. Różnią się od interfejsów tym, że mogą zawierać implementację metody. Tworzy się je przez

[PHP] pobierz, plaintext 
<?php
abstract class Klasa() {}
?>
[PHP] pobierz, plaintext 

?

Słowo abstract przed metodą klasy wymusza jej implementację w klasie dziedziczącej. Słowo final przed metodą nie pozwala przeciążyć metody w klasie dziedziczącej?

3. Klasa (abstrakcyjna lub konkretna) może zawierać metody statyczne i zwykłe. Do metod statycznych możemy się odwołać bez tworzenia instancji klasy. Metody statyczne tworzy się po to, żeby.. no właśnie po co?

Wroce do przykladu z ksiazki. Masz jakis mechanizm do otwierania i zamykania. I tak sobie zamykasz i otwierasz jakas klasa otwieraczem.
Otworzyc mozna: worek, plecak, sloik, drzwi.

Worek i sloik a takze reszta nie maja raczej nic wspolnego (no moze worek z plecakiem ale nie o to chodzi), wiec nie mozna zastosowac dziedziczenia bo niby co dziedziczyc ? Z trugiej strony chcesz miec pewnosc ze jak bedziesz uzywac klasy otwieracza to napewno przekazane do niego obiekty beda mialy metody otworz i zamknij. Stad zamiast tworzyc cztery klasy otieracze ktore przyjmuja argumenty na zasadzie addItem1(Worek $worek), addItem2(Plecak $plecak), to tworzysz jedna, ktora w argumencie przyjmuje klasy ktore implementuja interfejs otwierania np. AddItem(Otwieralne $objekt). I teraz masz pewnosci ze niewazne co przekazesz do otwieracza (pod warunkiem ze implementuje wskazany interfejs tu Otwieralne), mozesz wywolac metody zamknij i otworz. Krotki przyklad.

Przypuscmy ze otwieracz jest mala kolekcja zeczy do zamkniecia.

[PHP] pobierz, plaintext 
<?php
$otwieracz = New Otwieracz()
$otwieracz->addItem(New Plecak());
$otwieracz->addItem(New Slowik());
$otwieracz->closeAll();
?>
[PHP] pobierz, plaintext 

Teraz dodales do otwieracza trzy instancje klas implementujacych interfejs otwieralne. Mozesz wiec wywolac metode closeAll() ktora iterujac przez obiekty ktore dodales zamknie je wszystkie. Dlaczego taj jest ? Bo w deklaracji metody addItem klasy otwieracz pokazales jaki tym obiektu mozesz przekazac, czyli addItem(Otwieralne $objekt). Jesli sprobujesz inny to zglosi to blad, bo innego przekazac nie mozna. Sens jest tego taki, ze klasy nie musza po sobie dziedziczyc a ty i tak masz pewnosc ze mozesz uzywac na nich metod ktore musza implementowac bo taknakazuje interfejs.

Mam nadzieje ze nie pomotalem Ci za bardzo

Po co wszystko wymuszac. Nikt nie mowi ze wszystko, no ale wymuszac to po to po co opisalem wyzej, zeby miec pewnosc ze klasy mozna uzyc w miejscach w ktorych sie chce i nic sie nie wysypie. I po co wszyscy maja sie zapoznawac z kazda klasa w projekcie ? Trzeba by bylo analizowac jej kod i stwoerdzic ze nadaje sie do tego zeby jej obiekt przekazac do otwieracza, lepiej zeby wiedzieli ze implementuje ona(badz nie) interfejs otwieralne, wtedy bez zadnej praktycznie wiedzy, i bez znajomosci metody Otworz() Zamknij() wiedza ze moga ta klase przekazac do Otwieracza. Przeciez taki koder micro%^& nie zna kazdego zakamarka kodu Windowsa

1. To ze klasa implementuje interfejs nie oznacza ze nie moze miec innych metod.

2. Tak, jesli zaimplementujesz metode i dodasz do niej final, znaczy to ze nie moze byc ona przeciazona w klasach dziedziczacych. Slowo abstract jak najbardziej oznacza ze ta metode trzeba zaimplementowac w klasie dziedziczacej.

3. Co do metody statycznej. Wyobrazmy sobie cos takiego. Na poczatku skryptu tworzydsz instancje obiektu WebRequest ktory trzyma wszystkie POST GET COOKIE itp i pozwala operowac na nich tak czy inaczej. Teraz zapominasz o WebRequest, tworzysz jakas inna klase ktora gdzies tam w srodku uzywa zmiennych GET/POST czy cos tam. Po co korzystac z nich bezposrednio skoro klasa WebRequest zapewnia nam jakies metody do operacji na nich, i teraz co ? Musimy uzyc klasy WebRequest, tworzymy nowa instancje i uzywamy ? No ale po co ? Przeciez w skrypcie wystarczy nam tylko jedna instancja klasy WebRequest. I co z tym fantem zrobic ? Ano tutaj przychodzi nam na pomoc metoda statyczna. Jako ze nie wiesz czy w momencie w ktorym chcesz sie odwolac do metod WebRequest instancja tej klasy jest juz utworzona czy nie w klasie WebRequest implementujesz statyczna metode getInstance(). Przyklad.

[PHP] pobierz, plaintext 
<?php
class WebRequest {
 
	 private static $Instance = false;
 
	  public static function getInstance() {
			if(!self::Instance) {
				   self::Instance = New WebRequest();
			}
			return self::Instance;
	 }
}
?>
[PHP] pobierz, plaintext 

W ten sposob jesli musimy sie odwolac do metod WebRequest a wiemy ze nie potrzebujemy wiecej niz jednej jej instancji robimy $objekt = WebRequest::getInstance(); w ten sposob jesli instancja WebRequest nie zostala jeszcze utworzona zostanie utworzona, jesli istnieje zostanie zwrocona istniejaca. To jest wzorzec Singleton, dojdziesz do tego w Twojej ksiazce w rozdziale Warstwa Absrakcji dla bazy danych. Od razu mowie zebys nie wierzyl slepo w te przyklady tam bo sa fatalne. Ten sterownik dla PEAR DB to sciema

Jakbym pomotal Ci za bardzo to krzycz Jest sobota rano kaca mam