OOP. Interfejsy oraz klasy abstrakcyjne, Zabezpieczenie przed programistą? Opcje

[Sedziwoj]

menic stosowane są takie przykłady, aby każdy czytający je zrozumiał, bo pamiętaj że programiści zajmują się różnymi sprawami i nie zrozumiał byś pewnych przykładów.
Dlatego się tworzy takie abstrakcyjne przykłady, a powinieneś je znajdywać w swoim projekcie.

[Turgon]

Cysiaczek, a jakże dobry i prosty przykład. Tutaj warto stosować zasadę "Filtrowuj wszystko co się da". Dlatego na pewno nikt nie wrzuci nam np. do rejestru kolekcji obiektu routera

[splatch]

Troszkę inny przykład ...

[PHP] pobierz, plaintext 
<?php
// Definicje wspólne dla wielu obiektów
interface ILiveSchoolElement {} // na codzień w szkole
interface IPeople {} // jakaś osoba
interface ITeacher extends IPeople {} // nauczyciel
interface ILearner extends IPeople {} // uczeń
 
// Implementacja metod wspólnych
abstract class AbstractPeople implements IPeople {}
abstract class AbstractPeopleLiveSchoolElement extends AbstractPeople implements ILiveSchoolElement {}
 
// Specjalizacja, implementacja metod specyficznych
class Teacher extends AbstractPeopleLiveSchoolElement implements ITeacher {}
class Learner extends AbstractPeopleLiveSchoolElement implements ILearner {}
 
// i może na końcu ..
class Jacek extends Learner {}
?>
[PHP] pobierz, plaintext 

[LBO]

JA bym się przyczepił do jacka, bo:

[PHP] pobierz, plaintext 
<?php
$jacek = new Learner();
?>
[PHP] pobierz, plaintext 

Hehehe, pozdrawiam, ładny przykład.

[DeyV]

Korzystanie z interfejsów pokazuje swoje zalety w PHP szczególnie dzięki zastosowaniu SPL.
Wykorzystanie iteratora (czyli użycie foreach) lub zliczania elementów (count()) na obiekcie nie byłoby nigdy możliwe, gdyby nie odpowiednie interfejsy, wbudowane i wymagane przez te konstrukcje językowe lub funkcje.

Mi natomiast zasadność użycia interfejsów świetnie pokazała jeszcze inna sytuacja.

Mam różne rodzaje list pobieranych z baz danych. Niektóre z nich można sortować, inne stronnicować, jeszcze inne - filtrować. Niektóre mogą wszystko
Do każdego z tych zastosowań mam inną klasę, w stylu Pager, SorPanel, SearchPanel itp.

Oczywiste jest jednak, że do Pagera może trafić tylko lista, która potrafi być stronnicowana, więc Pager wymaga od otrzymywanego obiektu implementacji interfejsu Pageble.
Tak samo SortPanel itd. Dzięki temu bardzo łatwo, już na poziomie najprostszych testów sprawdzić, czy dana lista została poprawnie obsłużona.
W końcu nie tylko może mieć kilka interfejsów, które wymuszą na niej utworzenie odpowiednich metod, to jeszcze ewentualne błędy zostaną wykazane od razu po pierwszym odpaleniu testu (nie muszę fizycznie kliknąć w żaden link do stronnicowania )

[vegelus]

Przepraszam, że odgrzewam temat. Chciałbym poruszyć problem związany z interfejsami i myślę, że kontynuacja w tym wątku będzie odpowiednia.
Postanowiłem wykorzystać wzorzec kompozycji do zebrania kilku podobnych elementów, lecz z niewielkimi różnicami. Poniższy kod uprościłem do dwóch różnic. Do plecaka mogę włożyć element będący dzieckiem klasy abstrakcyjnej Item. Ale w zależności od materiału z jakiego jest wykonany dany element implementuje odpowiedni interfejs(szkło i drewno). Poniżej przedstawiam kod oraz proszę o podanie w jaki sposób w klasie Bag rozróżniać z jakiego materiału jest dany element aby wydać odpowiedni dźwięk.

[PHP] pobierz, plaintext 
<?php
class ItemExeption extends Exception {}
 
interface szklo{
	function brzdek();
}
interface drewno{
	function pukpuk();
}
 
abstract class Item {
	abstract function weigth();
 
	function addItem(Item $item){
		throw new ItemExeption(get_class($this)." to liść");
	}
 
	function removeItem(Item $item){
		throw new ItemExeption(get_class($this)." to liść");
	}
 
}
 
class butelka extends Item implements szklo {
	function weigth(){
		return 2;
	}
 
	function brzdek(){
		return 'Brzdek! Brzdek! ';
	}
}
 
class patyk extends Item implements drewno {
	function weigth(){
		return 4;
	}
 
	function pukpuk(){
		return 'Puk! Puk! ';
	}
}
 
class drewniane_luterko extends Item implements drewno, szklo {
	function weigth(){
		return 3;
	}
	function pukpuk(){
		return 'Puk! Puk! ';
	}
	function brzdek(){
		return 'Brzdek! Brzdek! ';
	}
}
 
class Bag extends Item {
	private $items = array();
 
	function addItem(Item $item) {
		foreach($this->items as $thisItem){
			if($item === $thisItem){
				return;
			}
		}
		$this->items[] = $item;
				//gdzieś tutaj chciałbym móc użyć czegoś takiego 
				if($item == 'szklo'){
					 $item->brzdek();
	}
	function removeItem(Item $item){
		$items = array();
		foreach($this->items as $thisItem){
			if($item !== $thisItem){
				$items[] = $thisItem; 
			}
		}
		$this->items = $items;
	}
	function weigth(){
		$ret = 0;
		foreach($this->items as $item){
			$ret += $item->weigth();
		}
		return $ret;
	}
}
 
$plecak = new Bag();
//wkladamy do plecaka butelke i sluszymy brzdek
$plecak->addItem(new butelka());
//wkladamy patyk i slyszymy pukpuk
$plecak->addItem(new patyk());
//sprawdzamy ciezar wlorzonych przedmiotow
print 'Plecak waży: '. $plecak->weigth() . ' kg.<br>';//wynik: Plecak waży: 6 kg.
 
?>
[PHP] pobierz, plaintext 

Ten post edytował vegelus 7.01.2008, 02:31:09

[mike]

Jest do tego gotowy operator: instanceof

[Virti]

A ja, jeśli można, chciałbym prosić o wytłumaczenie jak krowie na granicy po co w ogóle stosuje się klasy abstrakcyjne? Przeczytałem cały temat i niestety nie mogę tego zrozumieć.

[Whisller]

@Virti
Aby ułatwić sobie implementację Mały przykład kodu.

[PHP] pobierz, plaintext 
<?php
abstract class HeniuTreeNode 
{
	/**
	 * Ustawienie ID gałęzi
	 *
	 * @param int $id
	 */
	public function setId($id)
	{
		$this->id = $id;
	}
	public function getId()
	{
		return $this->id;
	}
 
	/**
	 * Ustawienie nazwy elementu
	 *
	 * @param string $name
	 */
	public function setName($name)
	{
		$this->name = $name;
	}
	public function getName()
	{
		return $this->name;
	}
 
	private $id	  = null;
	private $name = null;
}
?>
[PHP] pobierz, plaintext 

Oraz klasa dziedzicząca po niej

[PHP] pobierz, plaintext 
<?php
class HeniuTreeNodeNested extends HeniuTreeNode
{
// Tutaj cały kod
// Mamy dostęp do metod set/getId oraz set/getName
)
?>
[PHP] pobierz, plaintext 

I teraz wiesz że każda z klas odpowiadających za pojedyńczą gałąź będzie miała takie metody jak set/getId set/getName implementujesz je w klasie abstrakcyjnej po której będą dziedziczyć Twoje klasy i wtedy nie musisz już "przepisywać" ich na nowo (jeśli nie chcesz) w każej klasie z osobna.
Dzięki temu uzysujesz już wstępną implementację, a nic nie stoi na przeszkodzie aby w danej klasie nadpisać(jeśli jest taka potrzeba) te metody(set/getId czy set/getName)
Może to trochę zamotane ale ogólnie rzecz biorąc dużej polityki tutaj nie ma

[Virti]

Ok, czyli rozumiem, że abstrakcja dostarcza funkcji, które są używane przez kilka(naście) pochodnych klas, tak aby nie trzebabyło w każdej z osobna ich deklarować? W takim razie dlaczego nie stosować normalnych klas (nie-abstrakcyjnych) jako rodziców? Żeby zabezpieczyć się przed wywołaniem bezpośrednio tej funkcji?

[domis86]

@virti: żeby wymusic dziedziczenie po tej klase. Klasa abstrakcyjna to prototyp, szkielet, nie moze byc uzyta bezposrednio.

[Sedziwoj]

@vegelus
Wyjaśnij mi czym się różni "brzdek"/"pukpuk" od "dzwiek"?

[Cysiaczek]

Ja się zawsze staram robić klasy abstrakcyjne. Nazwa tego typu klas odzwierciedla to, czym ona jest. Widząc słówko abstract, natychmiast uzyskujemy informacje o tym, że implementacja jest w pochodnych, które tworzą jakąś rodzinę klas wyspecjalizowanych klas. Jak rozejrzymy sie po metodach tej klasy, będziemy wiedzieli, jakie operacje są wspólne, a jakie klasa wymusza w swoich pochodnych.
Stosując zwykła klasę bazową, te informacje będziemy musieli zdobyć sami przeszukując kod podklas.
To jest jedna z cech oop - ułatwienie zrozumienia logiki systemu.

Pozdrawiam.

[-=Peter=-]

Witam, może powinienem założyć nowy temat, ale wolę nie zaśmiecać forum Napotkałem problem, oto kod który wg mnie powinien działać:

[PHP] pobierz, plaintext 
<?php
interface A{}
 
interface B extends A{}
 
interface C{
   public function metoda(A $obiekt);
}
 
abstract class D implements C{
   public function metoda(A $obiekt){
	  //jakas implementacja
   }
}
 
class E extends D{
   public function metoda(B $obiekt){
	  parent::metoda($obiekt);
   }
}
?>
[PHP] pobierz, plaintext 

Problem jest taki, że wywala błąd że metoda E::metoda nie jest kompatibilna z interfejsem C::metoda... (Declaration of E::metoda() must be compatible with that of C::metoda()). Tak, jest inne wymuszenie typu w klasie D, ale podany typ jest dziedziczony po interfejsie który jest wymuszony w interfejsie C...

Czyli podsumowywując, jeśli chcemy wymusić typ w interfejsie to już nie da się później w klasach implementujących ten interfejs, w tej metodzie wymusić typ, który dziedziczy po typie wymuszonym pierwotnie w interfejsie? (mam nadzieje, że zrozumiecie o co mi chodzi ) Jak w takim razie to "obejść"? Czy może jest to jakiś bug w php5, albo dziwne i świadome ograniczenie? Bo na "chłopski rozum" powinno to działać.

EDIT: pytanie jak to "obejść" raczej jest nie na miejscu, bo wiem jak to obejść, tylko trochę to jest niewygodne

EDIT2: znalazłem już odpowiedź wg twórców php, nie jest to błąd. PHP nie sprawdza, czy rzutowany typ jest dziedziczony po tym, który został zrzutowany w interfejsie/klasie po której dana klasa jest dziedziczona. Wg mnie to trochę dziwne, no ale cóż poradzić...

Ten post edytował -=Peter=- 2.02.2008, 12:59:42

[Sajrox]

Wracająć do tematu to jak dobrze zrozumialem, interfejsy tylko i wyłacznie wymuszają utworzenie danych metod w klasie która implementuje dany interfejs

[-=Peter=-]

Interfejsy nie tylko wymuszają istnienie danych metod, ale także ustalają jaką deklarację ma mieć ta metoda (ile i jakiego typu ma mieć argumenty). W interfejsie możemy tylko wymusić istnienie publicznych metod, jest to z jednej strony logiczne, gdyż interfejs gwarantuje że dana rodzina klas będzie miała ten sam "protokół" do korzystania z nich, a z prywatnych czy chronionych metod nie skorzystamy z poza danej klasy.