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

[Sedziwoj]

Ale przy protected w klasie dziedziczącej jest widoczna, właśnie po to się ustawia tą widoczność aby nie można było jej z zewnątrz wywołać, ale w klasie dziedziczącej jak najbardziej.
Zacytuję, bo chyba tego nie widzisz:

i eśli ktoś chciałby dziedziczyć po klasie i używać tych metod, to już nie może, wtedy metoda musi być conajmniej protected.

wtedy musi być private

[Zeman]

Ale przy protected w klasie dziedziczącej jest widoczna, właśnie po to się ustawia tą widoczność aby nie można było jej z zewnątrz wywołać, ale w klasie dziedziczącej jak najbardziej.
Zacytuję, bo chyba tego nie widzisz:

wtedy musi być private

No to sie chyba faktycznie nie rozumiemy, bo poprawiasz mnie tak samo ja ja piszę.
Podsumowywując krótko i jednoznacznie:
private - metoda widoczna tylko w klasie w ktorej jest definicja tej metody, niewidoczna w klasach potomnych ani poza klasą
protected - tj private a dodatkowo widoczna w klasach potomnych
public - tj protected a dodatkowo poza klasą

[mike]

private - metoda widoczna tylko w klasie w której jest definicja tej metody, niewidoczna w klasach potomnych ani poza klasą
protected - tj private a dodatkowo widoczna w klasach potomnych
public - tj protected a dodatkowo poza klasą

Dziwisz się później, że nikt Cię nie rozumie. Napisz to jak po ludzku a nie się bawisz (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)
Jak protected to protected a nie jakieś "ale".

private - składowe klasy (pola, funkcje) widoczne (czyli dostęp do niech) tylko i wyłącznie wewnątrz klasy;
protected - składowe klasy, do których dostęp jest z wewnątrz klasy oraz wewnątrz klas dziedziczących.
public - składowe klasy do których dostęp można uzyskać w dowolnym miejscu aplikacji.

Ten post edytował mike_mech 3.04.2007, 21:19:43

[Turgon]

W mojej skromnej opinii, klasy abstrakcyjne, finale i interfejsy, to błogosławieństwo. Wiem to z doświadczenia, bo kod którego używam rozwijałem przez ponad rok w różnych odstępach czasu. Z dużą ilość modyfikacji, różnymi stylami programowania, ale zgodnie z OOP i teraz poprawia oraz używa się to cudownie.

Specjalnie dla niedomyślnego pana Athlana uzasadnienie:
Mam ok. 50 klas, które były pisane na przestrzeni 1 roku i gdyby nie jasno zdefiniowane interfejsy itp. , miałbym spore problemy, z powrotem do programowania, po przerwie jaką sobie ostatnio zrobiłem (2 miesiące).

Ten post edytował Turgon 4.04.2007, 18:22:43

[enigma]

[PHP] pobierz, plaintext 
<?php
 
interface ObrabiarkaTablic
{
  function obrobka($aTablica);
}
 
class Rodzic
{
  abstract function obrobka($aTablica)
  {
	// wykonanie jakis operacji
	return $aTablica;
  }
}
 
class Dziecko extends Rodzic implements ObrabiarkaTablic
{
  public function obrobka($aTablica)
  {
	// poprzednia filtracja danych:
	$aTablica = parent::obrobka($aTablica);
	// inna przerobka danych
}
 
?>
[PHP] pobierz, plaintext 

dołączę się do tematu (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) klasa Rodzic musi być abstrakcyjna chyba, tak (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

kurde czegoś tu nie rozumiem, no po co tak robić
class Dziecko extends Rodzic implements ObrabiarkaTablic
nie można by tylko
class Dziecko extends Rodzic
bo jakoś oprócz tego że wymuszają w klasie która dziedziczy zaimplementowanie odpowiednch funkcji nie widzę idei (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) proszę o jaśniejsze wytłumaczenie po co to używamy

Ten post edytował enigma 1.05.2007, 16:47:54

[dr_bonzo]

kurde czegoś tu nie rozumiem, no po co tak robić
class Dziecko extends Rodzic implements ObrabiarkaTablic
nie można by tylko
class Dziecko extends Rodzic
bo jakoś oprócz tego że wymuszają w klasie która dziedziczy zaimplementowanie odpowiednch funkcji nie widzę idei proszę o jaśniejsze wytłumaczenie po co to używamy

Interfejsy zostaly wziete z Javy, gdzie zmienna musi miec typ:

Kod

ObrabiarkaTablic ot = new Dziecko(); // jako ze dziecko implementuje ObrabiarkaTablic wiec jest typu ObrabiarkaTablic
ot = new XXXXXXX(); // gdzie XXXX..XX tez implemetuje ObrabiarkaTablic

a to wszystko po to zeby mozna bylo wykonac

Kod

ot.obrobka( tablica )

bo kompilator musi wiedziec czy na obiekcie 'ot mozna wywolac obrobka().

W PHP nie ma typowania zmiennych i mamy duck-typing, tzn. jesli na obiekcie wywolamy metode a on ja posiada to jest OK, czyli -> interfejsy sa niepotrzebne od strony wykonania, 'kompilacji' a bardziej do dokumentacji kodu, ogarniecia jego struktury

[Sedziwoj]

Tu po prostu Rodzic powinien implementować ObrabiarkaTablic, a wtedy nie trzeba dzieciom tego pisać, bo to jest z rodzica (jeśli się nie mylę przy takiej składni w Java też by nie było problemu)
A dodanie interfejsu to raczej kiedy rozszerzany jest rodzica, np. amfibia dziedziczy po samochodach, ale też implementuje łodzie, bo może pływać (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[enigma]

czyli -> interfejsy sa niepotrzebne od strony wykonania, 'kompilacji' a bardziej do dokumentacji kodu, ogarniecia jego struktury

czyli przy każtym projekcie robić sobie klasy abstrakcyjne i interfejsy (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

A dodanie interfejsu to raczej kiedy rozszerzany jest rodzica, np. amfibia dziedziczy po samochodach, ale też implementuje łodzie, bo może pływać (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

czyli wielodziedziczenie

oprócz tych dwóch, są jeszcze jakieś zastosowania ?

--EDIT
przeczytałem wszystkie topiki na forum o interfejsach i klasach abstrakcyjnych ale jeszcze czegoś mi brakuje (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) musze się z tym przespać (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

w jednej ksiżące znalazłem fajny przykład dla kals abstrakcyjnych
mamy klasę ssak no co to jest, nic konkretnego, nie można mieć obirektu klasy ssak, to byłoby bez sensu, więc robimy abstrakcję i dziedziczymy po niej (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)
chyba dobre (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) jeszcze żeby tak ładnie były interfejsy wytłumaczone (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Ten post edytował enigma 2.05.2007, 14:15:09

[menic]

Ale interfejsy sa bardzo proste do zrozumienia. Stosuje sie je najczęściej kiedy jakaś klasa moze byc wymieniona na inna. Np. handler sesji, Router. Wtedy w interefejsie zawierasz które metody są wymagane do poprawnego działania nowej klasy z pozostałymi i jazda (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

A co do przykladów... Ja nie wiem po co ludzie w tych wszstkich książkach dają te durne odniesienia do samochodów, zwierząt. Jak czytałem ksiązki to nigdy tego nie mogłem poją. Dopiero jak pracowałem z kodem to wszystko sie wyjasniło. Takie przykłady wprowadzają tylko bezsensowne zamieszanie.

Ten post edytował menic 13.05.2007, 10:14:31

[Cysiaczek]

Interfejsy to dla mnie głównie nowe typy, które można wymusić.
Proszę pominąć niedociągnięcia w implementacji

[PHP] pobierz, plaintext 
<?php
interface inteligencjaNaPewenymPoziomie{}
abstract class Ssaki{}
 
class Czlowiek extends Ssaki implements inteligencjaNaPewenymPoziomie{}
class Orangutan extends Ssaki{}
 
// 2  podobne, ale jakże różne klasy Budowniczy
 
class Budowniczy{
 
function budujSamolot(Ssaki $object){}
function budujSamolot(Ssaki $object); //orangutan z powodzeniem wybuduje na samolot : )
function malujWPaincie(Ssaki $object){} // orangutan i czlowiek mogą używać Painta(TM)
}
 
 
class Budowniczy{
 
function __construct(Ssaki $object){}
function budujSamolot(inteligencjaNaPewenymPoziomie $object){} // tutaj tylko obiekt typu inteligencjaNaPewenymPoziomie bedzie mógł wykonać zadanie
function malujWPaincie(Ssaki $object){} // orangutan zawsze może pomalować : P
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

Ten post edytował Cysiaczek 13.05.2007, 11:59:59

[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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) )

[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ę (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[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?