Witam,

Nigdzie nie moge doczytac jaka jest praktyczna roznica miedzy interfejsem i klasa abstrakcyjna. Teorie znam, interfejs definiuje nagłowki metod danej klasy, klasa abstrakcyjna ma wieksze mozliwosci, moze ponadto definiowac zawartosc metody.

Chodzi mi jednak jak to sie sprawdza w praktyce, kiedy zastosowac interfejs a kiedy klase abstrakcyjna, po co tak naprawde mam w ogole definiowac "ogolny zarys" klasy w interfejsie czy klsaie abstrakcyjnej?

Pozdrawiam

Interfejs sie najbardziej sprawdza kedy ty piszesz program i API do tego programu, wtedy zmuszasz uzerow do uzywania interfejsu, i wiesz jak np. wywolac ten mod.

Dam Ci definicję i przykład. Poprę się tym samym ksiązką "php 5 Nowe Możliwości"

1. Interfejsy
Przy pomocy interfejsów masz możliwość wymuszenia na klasach, aby posiadały niezbędne do współpracy z innymi elementami metody. Np. piszesz sklep i kążdy produkt musi mieć nazwę, cenę i numer identyfikacyjny. Robisz sobie interfejs:

[PHP] pobierz, plaintext 
<?php
interface Produkt{
 public function getName();
 public function getPrice();
 public function getID();
}
?>
[PHP] pobierz, plaintext 

We wnętrzu interfejsu definiuje się prototypy metod.
teraz każda klasa, która będzie implementowała ten interfejs musi posiadać podane metody. Np. klasa Book:

[PHP] pobierz, plaintext 
<?php
class Book implements Produkt{
  public function getName(){...}
  public function getPrice(){...}
  public function getID(){...}
}
?>
[PHP] pobierz, plaintext 

Jeśli klasa nie będzie posiadała wszystkich metod wymieniony w interfejscie php wygeneruje błąd krytyczny.


2. Klasy abstrakcyjne
Klasy te mają to do siebie, że nie można stworzyć ich kopii. Np. robisz sobie klasę Ziemia.

[PHP] pobierz, plaintext 
<?php
abstract class Ziemia{
  abstract public function Wirowanie();
  abstract public function Uderzenie_komety();
}
?>
[PHP] pobierz, plaintext 

Nie mogą istnieć dwie Ziemie

TomASS, ale widze ze to sie sprawdza tylko wtedy kiedy dajemy skrypt do rozbudowy przez innego programiste, bo przeciez sam i tak wiem jakie metody ma zawierac dana klasa...

Programowanie to zazwyczaj praca grupowa, dlatego powstają takie, a nie inne rozwiązania. Równie dobrze, można pisać w assemblerze, bo przecież nikt inny tego czytać nie będzie.

Interfejsy i klasy abstrakcyjne pomagają w uporządkowaniu struktury aplikacji. Pozwalają na zachowanie kontroli typów, dzięki czemu możesz się spodziewać określonego zachowania po danym obiekcie.

Klasy abstrakcyjne pozwalają na zdefiniowanie niektórych metod, dzięki czemu tworząc rodzinę klas, nie musisz dla każdej implementować funkcji takich jak getId(). Sprzyja to powstawaniu mniejszej ilości błędów (eliminujemy powtórzenia kodu). Drugą właściwością tych klas jest fakt, że nie możesz utworzyć z nich obiektu. Przydaje to się do tworzenia całkowicie statycznych klas.

Nie koniecznie dla innego programisty. Piszac duza aplikacjie (tzn zlozona), w koncu zapomnisz o czyms. Interfejsy ratuja wtedy skore

Klase definiuje sie jako abstrakcyjna w chwili, kiedy nie chcesz aby ktos utworzyl jej obiekt. Taka klase da sie tylko dziedziczyc, co w praktyce oznacza ze klasa abstrakcyjna nie jest kompletne klasa. Dziedziczenie uzupelnia klase i wtedy mozemy stworzyc dzialajacy obiekt. Pokaze na przykladzie:

Mamy w aplikacji klase wyswietlajaca dane (widok w MVC). Czesto piszemy kilka widokow - np. taki wyswietlajacy dane na podstawie szablonow php. Do tego doliczmy, ze mozemy miec widok wyswietlajacy dane jak leci oraz taki, ktory udekoruje je o cala strone (stopka, naglowek, menu itp.).

Wiadomo, ze takie widoki powinny miec metody taki, jak:

[PHP] pobierz, plaintext 
<?php
 
interface IView
{
  public function setAttribute($sAttributeName, $mAttributeValue);
  public function setAttributesArray($aAttributeArray);
 
  public function getAttribute();
  public function removeAttribute($sAttributeName);
 
  public function __get($sAttributeName);
  public function __set($sAttributeName, $mAttributeValue);
 
  public function display();
  public function fetch();
}
 
?>
[PHP] pobierz, plaintext 

W ten sposob zdefiniowalismy interfejs dla klas widoku. Od tech chwili, kazda implementujaca klasa ten interfejs bedzie musiala je miec.

Ale pomyslmy przez chwile. Czy klasa widoku normalna i dekorujaca nie bedzie miala takich samych metod getAttribute(), removeAttribute(), __set(), __get()? Po co powielac kod - napiszemy klase abstrakcyjna:

[PHP] pobierz, plaintext 
<?php
 
abstract class View implements IView
{
  private $_aAttributes;
 
  public function __construct()
  {
	$this->_aAttributes = array();
  }
 
  public function setAttribute($sAttributeName, $mAttributeValue)
  {
	$this->_aAttributes[$sAttributeName] = $mAttributeValue;
  }
 
  public function setAttributesArray($aAttributeArray)
  {
	$this->_aAttributes = array_merge($this->_aAttributes, $aAttributeArray);
  }
 
  public function getAttribute()
  {
	if(func_num_args() == 0)
	  return null;
	$aArgs = func_get_args();
 
	$aCurrentAttribute = $this->_aAttributes;
 
	foreach($aArgs as $sKey => $sAttributeName)
	{
	  if(isset($aCurrentAttribute[$sAttributeName]))
		$aCurrentAttribute = $aCurrentAttribute[$sAttributeName];
	  else
		return null;
	}
 
	return $aCurrentAttribute;
  }
 
  public function removeAttribute($sAttributeName)
  {
	if(isset($this->_aAttributes[$sAttributeName]))
	  unset($this->_aAttributes[$sAttributeName]);
  }
 
  public function __get($sAttributeName)
  {
	$aAttributes = explode(_LANGUAGE_SEPARATOR, $sAttributeName);
	return call_user_func_array(array($this, 'getAttribute'), $aAttributes);
  }
 
  public function __set($sAttributeName, $mAttributeValue)
  {
	$this->setAttribute($sAttributeName, $mAttributeValue);
  }
 
  public function display()
  {
	echo $this->fetch();
  }
}
 
?>
[PHP] pobierz, plaintext 

Dlaczego klasa musi byc abstrakcyjna:
1. Pominmy slowo kluczowe abstract. Proba utworzenia obiektu tej klasy zakonczy sie bledem. Klasa przeciez nie definiuje metody fetch(), ktora wymusza interfejs.

2. Nie chcemy przeciez utowrzyc (najczesciej przez pomylke) obiektu widoku, ktory nie dziala. Lepiej rozszerzac klase (dziedziczyc od niej). W ten sposob zbudujemy klasy widokow, ktore dzialaja, a maja mniej kodu (bo przeciez dziedzicza z tej klasy abstrakcyjnej).

A jak wyglada przykladowy widok?

[PHP] pobierz, plaintext 
<?php
 
class BasicHtmlView extends View
{
  private $_sTemplate;
 
  public function fetch()
  {
	if(!isset($this->_sTemplate))
	  throw new ViewException('The template has not been specyfied');
 
	$sTemplateFileName = _DIR_APPLICATION_TEMPLATES . $this->_sTemplate . 'Action.php';
 
	if(!is_readable($sTemplateFileName))
	  throw new ViewException('The template ' . $this->_sTemplate . ' does not exist');
 
	ob_start();
 
	require_once($sTemplateFileName);
 
	$sFetched =  ob_get_contents();
	ob_clean();
 
	return $sFetched;
  }
 
  public function setTemplate($sTemplateName)
  {
	$this->_sTemplate = $sTemplateName;
  }
}
 
?>
[PHP] pobierz, plaintext 

Dodam jeszcze, ze nowy widok nie musi juz implementowac interfejsu, poniewaz dziedziczy implementacje z klasy abstrakcyjnej,

Proste i wygodne

Pozdrawiam, Adrian.

Interfejsy uwalniają nas w pełni od jakiejkolwiek implementacji.
Klasy abstrakcyjne zawierają już implementację niektórych mechanizmów, które zachowują się w ten sam sposób w wielu miejscach. Możesz określić wewnątrz klasy abstrakcyjnej wszystkie metody jako finalne i jedną jako abstrakcyjną, którą powinna implementować tylko klasa wyspecjalizowana.

Są ludzie, którzy twierdzą, że zanim napiszesz jakąkolwiek klasę powinieneś stworzyć interfejs. Trudno się z nimi niezgodzić.. sam powoli zaczynam stosować tą praktykę i muszę przyznać, że jest ona bardzo użyeczna.

TamASS ładnie wytłumaczył.
Warto dodać jeszcze jedną dość ważną rzecz.
Otóż w php można dzidziczyć jedynie po jednej klasie, natomiat interfaców, można implementować wiele

Więc kontynując post TomASS'a, w kodzie mozemy stworzyć:

[PHP] pobierz, plaintext 
<?php
class CookBooks implements IBook, IProduct {
// ....
}
?>
[PHP] pobierz, plaintext 

W naszym sklepie mamy książkę kucharską, która jest produktem - ksiązką Więc musi posiadać metody interfejsu produktu oraz książki.

W telegraficznym skrócie.
Bez odbioru.

Nie kopii, a obiektów. Trzeba je wydziedziczyć i nadpisać wszystkie metody abstrakcyjne.
Dwa obiekty mogą być typu Ziemia. Co prawda pośrednio, bo musisz wydziedziczyć Ziemia, ale zawsze.

Kopii


Zależy jak na to spojżeć Wg. mnie nie możesz zrobić czegoś takiego:

[PHP] pobierz, plaintext 
<?php
$ziemia1 = new Ziemia();
$ziemia2 = new Ziemia();
?>
[PHP] pobierz, plaintext 

Oczywiście masz rację, jeśli chodzi o "pośredniość" i "wydziedziczenie".

Oczywiście, że nie można bo jak napisałeś, Ziemia to klasa abstrakcyjna, a nie dlatego, że może posiadać tylko jedną instancję.

Skoro tak mówisz Poddaję się i przyznaję, że masz rację

Dobrze mówi ponieważ nie można tworzyć instancji klasy abstrakcyjnej.
Poprostu klasą abstrakcyjną w tym przypadku powinno być Planet, a ziemia powinna odziedzić planet czyli EarthPlanet() etc.

Hm, roznica wydaje sie byc nieznaczaca, ale jednak jest. W intrefejsie podajemy tylko nazwy metod, a w klasie abstrakcyjnej mozemy w takiej metodzie zawrzec jakies dzialanie. Po co? - odpowiedz jest prosta jesli nasza metoda (w interfejsie) ma 10 linijek kodu, interfejsu uzywamy w 10 klasach, a metoda dla niech jest taka sama, to po co pisac 10x10 linijek kodu wiecej, skoro mozna zrobic abstrakcyjna klase z metoda juz zdefiniowana i pozostale klasy zrobic jej dziecmi?

Mi wydaję się, że różnica jest bardzo duża Ostatnio np. pisałem klasę która miała około 20 metod, w tym chyba 2 abstrakcyjne -> klasy dziedziczące nadpisywały tylko te dwie metody. Tutaj klasa abstrakcyja była bardzo fajnym rozwiązaniem.

Interfejs ma natomiast inną przewagę: jedna klasa może implementować bardzo wiele interfejsów.
Druga kwestia, taka może troche bardziej koncepcyjna, to to, że klasa abstrakcyjna zazwyczaj jest dość mocno związana z obiektami dziedziczącymi w sensie logicznym -> czyli np. jak ktoś mówił tworzysz klasę Planet a potem wszystkie planety dziedziczą po tej klasie.
Interfejsc natomiast nie musi być już tak mocno związany z daną klasą -> np możesz stoworzyć interfejs Idestroyable, który mówi że dany obiekt może zostać zniszczony. Taki interfejs możesz nadać zarówno obiektomy klasy Planet, Star, Person, Car itp.

Różnica IMHO jest dość znaczna, ale wychodzi dopiero w większych projektach, gdzie trzeba śledzić wiele zależności itp. W małych projektach typu strona z panelem admina różnica jest często praktycznie niewidoczna.