OOP & Interfejsy Opcje

[KirkoR]

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.

[krzysztof f.]

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ą.

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

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 

bo polimorfizm w php praktycznie nie istnieje.

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.

krzysztof f.: jeśli dobrze zrozumiałem, to twoje filtry działają tak, że każdy filter powinien mieć dwa pliki...

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.