Witam. Czy ktoś może mi przedstawić szerzej idee interfejsów, do czego służą, kiedy i po co ich uzywać? Bo nigdzie nie mogę znaleźć konkretnych informacji.

A naprawdę szukałeś :?:
forum.php.pl -> search -> interfejs
Working with Class Types: Abstract Classes and Interfaces

Drugi link od mike_mech powinien wszystko wyjaśnić.

Na wszelki wypadek ;)

Interfejsy pozwalają pisać lepiej zorganizowany, czytelniejszy kod oraz oddzielać implementację od właśnie interfejsu. Założenia programowania obiektowego mówią o tym, że powinno się pisać kod bardziej ukierunkowany na interfejs, niż samą implementację. Ułatwia to późniejsze ponowne wykorzystywanie kodu i współpracę między projektantami/programistami. Programowanie (w szczególności programowanie komponentowe http://c2.com/cgi/wiki?ComponentOrientedProgramming) to nie tylko pisanie aplikacji dla końcowego użytkownika. Obecnie programiści piszą kod, który jest wykorzystywany/kupowany później przez innych programistów. Aby praca z obcymi komponentami czy bibliotekami była jak najłatwiejsza, czy też w ogóle możliwa, muszą one dostarczać czytelne API http://en.wikipedia.org/wiki/API. Programistę wykorzystującego taki komponent nie interesuję implementacja (czyli w jaki sposób działają poszczególne zadania), a jedynie interfejs (czyli jakie zadania ma możliwość wykonać).

Mówiąc prościej… interfejs w odniesieniu do obiektu to po prostu lista metod jakie obiekt posiada wraz z typami niezbędnych parametrów i informacją o zwracanej wartości. php umożliwia wymuszanie jedynie typów obiektowych jako parametrów funkcji. Gorzej jest z wartościami zwracanymi, ale ma się to zmienić http://www.php.net/~derick/meeting-notes.h...d-return-values. Póki co jedyny sposób to dobra dokumentacja kodu http://phpdoc.org/.
W taki sposób znając interfejs obiektu wiemy jak go używać. Bo zgodnie z ideą interfejsu wszystkie jego metody muszą być publiczne.

Jak sprawa ma się w praktyce?

Załóżmy, że mamy napisaną aplikację opartą o Front Controller http://www.phppatterns.com/docs/design/the...troller_and_php, który stanowi punkt wejścia do naszej aplikacji. Możemy w nim rejestrować filtry http://java.sun.com/blueprints/corej2eepat...tingFilter.html, które będą wykonywały jakieś operacje na danych wejściowych i wyjściowych. Idea polega na tym, że wykorzystując nasz kontroler w różnych przypadkach, możemy dowolnie komponować zestawy filtrów, lub też tworzyć nowe w miarę potrzeb. W tym celu tworzymy interfejs filtru, z którym będzie współpracował obiekt kontrolera.

[PHP] pobierz, plaintext 
<?php
interface IInterceptingFilter
{
   /**
	* Operacje wykonywane przed wywołaniem kontrolera
	*
	* @param Request Obiekt żądania
	* @return Request
	* @access public
	**/
   public function preProcess( Request $oRequest );
   
   /**
	* Operacje wykonywane po obsłudze żądania
	*
	* @param Response Obiekt odpowiedzi
	* @return Response
	* @access public
	**/
   public function postProcess( Response $oResponse );
}
?>
[PHP] pobierz, plaintext 

Stwórzmy teraz przykładowy filtr:

[PHP] pobierz, plaintext 
<?php
class TimeExecutionFilter implements InterceptingFilter
{
 
   /**#@+
	* @var string 
	* @access private 
	*/
   /**
	* Data rozpoczęcia skryptu (format microtime) 
	*/
   private $_sStart;
   /**
	* Data zakończenia wykonywania skryptu (format microtime) 
	*/
   private $_sEnd;
   /**#@-*/
 
 
   public function preProcess( Request $oRequest )
   {
	  $this->_sStart = microtime();
	  return $oRequest;
   }
   
   public function postProcess( Response $oResponse )
   {
	  $this->_sEnd = microtime();
	  return $oResponse->set( 'time', $this->_calculateTime( $this->_sStart, $this->_sEnd ) );
   }
 
   /**
	* Przeliczenie czasu wykonania strony
	* 
	* @param string Czas rozpoczęcia (format microtime)
	* @param string Czas zakończenia (format microtime)
	* @return double Czas wykonania w sekundach
	* @access private
	**/
   private function _calculateTime( $sStart, $sEnd )
   {
	  $aEnd = explode( ' ', $sEnd );
	  $aStart = explode( ' ', $sStart );
 
	  $dEnd = (float) $aEnd[1] + (float) $aEnd[0];
	  $dStart = (float) $aStart[1] + (float) $aStart[0];
 
	  return number_format( $dEnd - $dStart, 4);
   }
}
 
?>
[PHP] pobierz, plaintext 

Z czasem rozwoju aplikacji może się okazać, że przydałby nam się jeszcze inne filtry. Nie ma problemu wystarczy, że zaimplementujemy na nowo nasz interfejs lub zlecimy to komuś innemu. Tak długo jak będziemy trzymać się interfejsu kontroler będzie potrafił sobie z nim poradzić, a my będzimy mogli go spokojnie używać. Chociażby w taki sposób:

[PHP] pobierz, plaintext 
<?php
   $oController = new FrontController();
   $oController->addFilter( new AuthenticationFilter( 'login.php' ) );
   $oController->addFilter( new OutputBufferFilter() );
   $oController->addFilter( new TimeExecutionFilter() );
   $oController->run();
 
?>
[PHP] pobierz, plaintext 

Ja filtry inaczej rozwiązałem. Nie mam 2 metod pre i post, tylko jedną: executeFilter. A niej jest $this->executeNext() co uruchamia następny filterek jaki jest w łańcuszku aż do ExecFiltra który to odpala akcje. Oczywiście jeśli będzię kod przed executeNext, zostanie to potraktowe jako pre filter, a po metodzie execNext jako post filter.

I o to chodzi. Cała idea wzorców poleg przecież na tym, że podają one sposób rozwiązania jakiegoś złożonego problemu, a implementację zostawiają programiście pozwalając na dużą swobodę. Moja implementacja filtrów z koleji wygląda mniej więcej tak:

Czyli jesli dobrze zrozumiałem, to narzucenie podanych method w interfejsie ?

Swoją drogą, filtry zrobił bym tak:

Klasa Filter, która 'przechowuje' dany filter, potem wrzucamy do ExecuteFilter w którym jest tylko metoda np. process, która uruchamia Filter jako plugin.

Ja może krótko..

Klasy stosujemy jezeli jest zaleznosc "jest jakims\jakas", w przeciwnym wypadku nie zachodzi potrzeba dziedziczenia i stosuje sie szybsze interfejsy.

Oczywiście, przecież interfejs ma za zadanie wymusić konkretne metody publiczne w implementującej klasie, w szczególnych wypadkach nie ma wcale metod np. interfejs Serializable, który pozwala na serializowanie obiekt, to bardziej z Javy chociaż ostatnio chyba też w SPL widziałem.


Hmm, trochę nie kumam ;]
Ja stosuję dziedziczenie tam gdzie chce użyć metod klas rodziców. Czy ja wiem czy interfejsy są szybsze, po prostu nie mają ciała metod. Zresztą tylko interfejsy przydają się głównie przypisaniu aplikacji i pozwalają wykryć za wczasu, że nie ma konkretnej metody, bo polimorfizm w php praktycznie nie istnieje.

Bela - nigdy do konca nie wnikałem jak to jest w php gdyz nie interesuja mnie to

W C# naprzykład interfejsy sa szybsze niz dziedziczenie, pozatym badz co badz zajmuja mniej pamieci.

Jezeli potrzebujesz uzywac metod, to znaczy ze ta relacja zachodzi, ale wprowadzanie jej na hama jest poprostu dlamnie absurdem

outputBufforPlugin jest Pluginem wiec dziedziczenie powinno zajsc (chyba ze nasza klasa Plugin jest "czysta" i nie ma jakiegos api wykozystywanego gdzies tam)

krzysztof f.: jeśli dobrze zrozumiałem, to twoje filtry działają tak, że każdy filter powinien mieć dwa pliki.
1. Jeden plik, który zawiera 'suchy' kod, który jest jakby mózgiem filtru.
2. Drugi plik, który będzie wykonywał całą robotę.
Cały filter leci do FilterChain, który jest zarządzany przez FilterManager, który kieruje filtry do iteratora z ArrayAccess i jesli potrzeba to wyświetla wynik. uf..

Zgadza sie, masz bazowa klase plugin z abstrakcyjnymi metodami execute() (czy jakos tam) i je przeladowujesz.

Z JAVY (Java 2 Podstawy) cytat ze skrotami (nie chce mi sie tyle przepisywac) [moje dopiski]:
"W javie interfejs nie jest klasa ale zbiorem wymagan dotyczacych klas, ktore chca dostosowac sie do interfejsu

Zazwyczaj dostawca pewnych uslug stwierdza: Jesli twoja klasa jest dopasowana do danego interfejsu, to wykonam usluge. (...) Metoda sort klasy Arrays obiecuje posortowac obiekty tablicy, ale pod jednym warunkiem: obiekty musza nalezec do klas implementujacych interfejs Comparable [nie musza byc tej samej klasy!!!] [musza zaimplementowac jedyna metode: int compateTo( Object innyObiekt );]"

Metoda Arrays.sort() pobiera obiekt "typu" Comparable[] (interfejsy zastapily (w pewnym stopniu) wielokrotne dziedziczenie) -- czyli tablice obiektow implementujacyhc interfejs Comparable i jes sortuje.

Interfejs (np. Telewizora -- przysicki: ON/OFF, Vol+, Vol-, P+, P- ) okresla metody jakie musi zaimplementowac obiekt aby inny obiekt/user (user TV) znajacy obsluge tego interfejsu mogl sie nim poslugiwac (umiesz obsluzyc jeden telewizor, obsluzysz tez setke innych bez czytania manuala). Oczywiscie obiekt moze implementowac inne interfejsy (TV+Mikrofalowka, co co? ), co nie przeszkadza userowi znajacy tylko jeden z nich uzuwac tego obiektu.

Inny przydlad: interfejs Zepsuwalne (ale glopie slowo) (jedyna medoda: void zepsuj()), jestes typem czlowieka ktory lubi wszystko psuc (taka abstrakcja, jakby co:)). Obiekty implementujace ten interfejs: TV, Video, Komp, MAC, PC, Sun, Impreze, Atmosfera. Dzieki temu ze implementuja ten interfejs mozesz uzyc na nich metody zepsuj(), nawet jak nie posiadaja wspolnej klasy bazowej.

ufff... DA-END

hmmm

Rozważania na temat w jakich sytuacjach stosować interfejsy a kiedy tworzyć klasy abstrakcyjne są jak najbardziej na miejscu. Nie ma to jednak nic wspólnego z prędkością czy wydajnością.



hwao czy mógłbyś przedstawić jakieś testy wydajnościowe, które ktoś wykonywał i które potwierdzają Twoją teorię? Błędem jest stawianie interfejsów na równi z dziedziczeniem. Obydwa pojęcia oznaczają coś innego i nie są wymienne.

Kiedy potrzebujemy z jakiegoś powodu określić jedynie zestaw metod publicznych dla pisanych w przyszłości klas, nie zajmując się implementacją stosujemy interfejsy. Natomiast gdy na tym etapie pojawia się jakaś wspólna logika dla rodziny klas, którą warto jest zawrzeć w klasie bazowej stosujemy klasy abstrakcyjne. To oczywiście duże uproszczenie, a różnic jest dużo więcej. W php np. nie mamy możliwości dziedziczenia po więcej niż jednej klasie, ale możemy za to implementować więcej niż jeden interfejs, a nawet rozszerzać interfejsy po kilku innych. Ilustruje to przykładowy kod:

[PHP] pobierz, plaintext 
<?php
interface IA
{
   public function aa();
}
 
interface IB
{
   public function bb();   
}
 
interface IAB extends IA, IB
{
   public function ab(); 
}
 
 
class AB implements IAB
{
	public function aa()
	{
	  echo 'A_B::aa()';	   
	}
 
	public function bb(  )
	{
	  echo 'A_B::bb()';	   
	}
 
	public function ab(  )
	{
	  echo 'A_B::ab()';
	}
}
 
$oAB = new AB();
 
echo $oAB->aa(); // A_B::aa()
echo $oAB->bb(); // A_B::bb()
echo $oAB->ab(); // A_B::ab()
 
?>
[PHP] pobierz, plaintext 

Jak to?? Już w php4 można było stosować dziedziczenie http://www.php.net/manual/en/keyword.extends.php, które jest przecież głównym narzędziem polimorfizmu.



Prawie : ) Każdy nowy filtr to dokładnie jedna klasa (i jeden plik) dziedzicząca po abstrakcyjnej klasie InterceptingFilter. Kod klienta operuje jedynie na obiekcie FilterManager, który ukrywa przed nim całą obsługę filtrów. Tworząc instancję menadżera filtrów podajemy w konstruktorze FilterManager::__construct() referencję do docelowego obiektu Target, który wykonuje jakąś operację poprzedzaną i zakańczaną działaniem filtrów. Obiekt Target, podobnie jak filtry, musi implementować interfejs IProcessor. Następnie używając metody FilterManager::addFilter() dodajemy zestaw potrzebnych nam filtrów i w odpowiednim momencie odpalamy przetwarzanie FilterManager::processFilter(). Zgdonie z ideą filtrów, FilterManager::processFilter()wywoła metody InterceptingFilter::preProcess() wszystkich filtrów w kolejności ich dodawania, następnie Target::execute() i metody InterceptingFilter::postProcess() w odwrotnej kolejności.

Wiem ze oznaczaja co innego, aczkolwiek moga miec "podobne zastosowanie". Co do teori, to jest ona oparta na na ksiezce o c# napisanej przez jednego z tworcow tego jezyka.