Witam.

Nie rozumiem paru rzeczy w programowaniu obiektowym, mianowicie sensu interfejsów i abstrakcji. Przecież taki interfejs w ogóle jest niepotrzebny i tylko zwiększa (nieznacznie) rozmiar naszego pliku, albowiem on tylko wymusza zdefiniowanie jakiejś metody. Ogólnie tą metodę możemy zdefiniować bez żadnego interfejsu - efekt ten sam.

[PHP] pobierz, plaintext 
<?php
//******************** kod 1
interface intf {
   public function example();
}
class klasa implements intf {
   public function example() {
      echo 'Example function';
   }
}
//********************
//******************** kod 2
class klasa {
   public function example() {
      echo 'Example function';
   }
}
//********************
// Efekt? Ten sam, a zatem po co te interfejsy??
?>
[PHP] pobierz, plaintext 

Abstrakcji też nie rozumiem. Przecież ów deklaracja jest absolutnie niepotrzebna; można to zrobić w klasie, która coś dziedziczy.

[PHP] pobierz, plaintext 
<?php
//*************** kod 1
abstract class abstr {
   abstract public function absfunc ();
   public function example () {
      echo 'example';
   }
}
class klasa extends abstr {
   public function absfunc () {
      echo 'abstr';
   }
}
//***************
//*************** kod 2
class notabstr {
   public function example () {
      echo 'example';
   }
}
class klasa extends notabstr {
   public function absfunc () {
      echo 'abstr';
   }
}
//***************
// Efekt? Ten sam...
?>
[PHP] pobierz, plaintext 

Ogólnie nie widzę sensu w użytku tego - jest to używane tylko do debugowania albo przejrzystości czy jak? Bo ogółem nie ma to innego sensu raczej.

http://forum.php.pl/index.php?showtopic=111328
https://forum.4programmers.net/Java/221811-...wie_je_stosowac

Po pierwsze stosuje się PSR-4 http://www.php-fig.org/psr/psr-4/ i interface, trait oraz wszystkie klasy powinny być definiowane w osobnych plikach.
Po drugie implementacja interface w klasie wymusza własną implementację danej metody czyli w twoim pierwszym przykładzie intf::example(). Strukturyzuje też kod.
Załóżmy gdybyś miał:

UserStorageInterface.php

[PHP] pobierz, plaintext 
interface UserStorageInterface {
  public function fetchById($id);
  public function fetchAll();
}
[PHP] pobierz, plaintext 

DbUserStorage.php

[PHP] pobierz, plaintext 
class DbUserStorage implements UserStorageInterface {  
}
[PHP] pobierz, plaintext 

ArrayUserStorage.php

[PHP] pobierz, plaintext 
class ArrayUserStorage implements UserStorageInterface {  
}
[PHP] pobierz, plaintext 

ExternalServiceUserStorage.php - czyli dane pochodzące z obcych serwisów pobierane przez API

[PHP] pobierz, plaintext 
class ExternalServiceUserStorage implements UserStorageInterface {  
}
[PHP] pobierz, plaintext 

W każdej z klas musiałbyś zaimplementować pobieranie danych o użytkownikach. Metoda na zrobienie tego byłaby różna w zależności od klasy (wybranie z bazy, pobranie z tablicy albo z zewnątrz) ale miałbyś pewność że klasy te posiadają daną metodę. I teraz jeszcze ważniejsze:

[PHP] pobierz, plaintext 
$dbUserStorage = new DbUserStorage;
var_dump($dbUserStorage instanceof UserStorageInterface);
// bool(true)
[PHP] pobierz, plaintext 

Oraz co za tym idzie rzutowanie:

UserRepository.php

[PHP] pobierz, plaintext 
class UserRepository {
    /**
     * @var UserStorageInterface
     */
    private $userStorage;
 
    /**
     * UserRepository constructor.
     *
     * @param UserStorageInterface $userStorage
     */
    public function __construct(UserStorageInterface $userStorage)
    {
        $this->userStorage = $userStorage;
    }
}
[PHP] pobierz, plaintext 

Dzięki temu do klasy UserRepository możesz przekazać dowolny obiekt który implementuje UserStorageInterface.

Jakiś czas temu pisałem też o klasach gdzie masz wytłumaczoną abstrakcję.

Na początku programowania OO też nie rozumiałem w ogóle co to interface i abstract class.

Aktualnie rozumiem to w ten sposób że:

Interfejs i Klasa Abstrakcyjna jest to narzucony przez programistę sposób nazewnictwa metod, taka instrukcja dla innych programistów, lub dla siebie samego.

Interfejs zawiera jedynie deklarację metod, klasa abstrakcyjna może zawierać dodatkowo działające abstrakcyjne metody.

Pisząc swoje proste aplikacje/frameworki nie stosowałem nigdy interfejsów, natomiast bardzo często pisałem klasy abstrakcyjne, może za często.

Z tymi "działającymi abstrakcyjnymi metodami" to się chyba trochę zagalopowałeś. W skrócie interfejs tym różni się od klasy abstrakcyjnej, że definiuje co robi dana klasa, a nie jak.

Interfejs jest po to abyś mógł podpowiedzieć sobie lub innemu programiście czego oczekujesz od danego obiektu klasy, co powinien on umieć zrobić. Gdy np. przyjmujesz obiekt poprzez dependency injection, jak zostało to pokazane wyżej w UserRepository, to możesz się spodziewać że przekazany Ci obiekt będzie robił to co interfejs UserStorageInterface mu każe. Oznacza to że spokojnie w innym miejscu możesz wywoływać na danym obiekcie metody zaimplementowane z interfejsu UserStorageInterface bez obaw że ich tam nie ma i że dostaniesz fatal error podczas wykonywania kodu. Gdy natomiast jesteś zainteresowany tym by skorzystać z UserRepository to od razu wiesz jakie metody powinieneś zaimplementować w swoich obiektach.

Interfejsy są rozwiązaniem wielodziedziczenia, które znane jest z c++, wiec jak potrzebujesz przykładowo 2 klasy które będą miały takie same metody, ale ich działanie będzie inne to najłatwiej zrobić dla nich interfejs i wtedy masz uporządkowana strukturę, a klasa abstrakcyjna to częściowa cześć wspólna dlatego nie da sie stworzyć obiektu takiej klasy. W php mamy jeszcze cechy

@com to co napisałeś to nie jest wielodziedziczenie Wielodziedziczenie jest wtedy gdy klasa dziedziczy po kilku klasach. Namiastką tego są Traits.

Przykład z moich ostatnich wojów. Mam sobie Commands (kilka różnych). Tworzę sobie rozszerzoną wersję każdego. Siłą rzeczy robię extends dla każdego z odpowiedniego Commands.
Jednak moje commands mają wspólne metody. I tu by się przydało wielodziedziczenie żeby wypchnąć te metody do innego wspólnego Command, ale nie da się. I tu wchodzi Traits.

Traitsy jak najbardziej mają sens, zmniejszają rozmiar pliku + nie musisz kopiować tych samych rzeczy do różnych klas. Po prostu mniej pracy.

Hmm, no cóż, może kiedyś postanowię jednak używać te interfejsy i abstrakcje. Przynajmniej ujrzałem jakieś możliwe zastosowanie, dziękuję.

A tak poza tym czemu trzeba dołączać wszystkie klasy w oddzielnych plikach? Osobiście uważam, że wolę mieć deklaracje klas w innym pliku niż ten, w którym będą mi one potrzebne - mniej scrollowania itp., ale czemu każda klasa w oddzielnym pliku? Ma to w ogóle jakiekolwiek znaczenie?

Nie trzeba ale ułatwia to czytanie kodu.
Łatwiej jest szukać metody getUserId z klasu Users która jest w pliku users.class.php niż w pliku allClasses.php

Robi się tak ze względu na autoloader który automatycznie mapuje nazwę pliku na nazwę klasy. I jest dużo bardziej czytelne.
A juz na pewno nie używa się teraz.class.php. to było za czasow początków PHP 5.

Pyton_000 ja wiem co to wielodziedziczenie, może źle się wyraziłem, w cpp było wielodziedziczenie, którego ludzie strasznie nie lubili w takiej postaci w jakiej było, stad wzrosła popularność interfejsów i klas abstrakcyjnych, które pozwalały w takich językach jak np java stworzyć namiastkę tego co było w cpp ale innym sposobem.

No ale jak masz klasę Foo, która będzie abstrakcyjna i cześć wspólna zaimplementujesz a resztę pozostawisz ew nadpiszesz w pochodnej, to da się nie używać traintów

przykład https://github.com/zendframework/zend-diactoros to dało sie napisac znacznie prościej bez traitów, które bardzo często zaciemniają tylko kod

Hej @IAmBoskiM widze, że jestes w dość podobnej sytuacji co ja Tyle, że ja już zrozumiałem co to są interfejsy/abstrakcje i po co

Generalnie masz bardzo dużo racji: one są niemal niepotrzebne w starszych wersjach PHP. W najnowszej 7.0 już jest lepiej ale nadal niedoskonale. Ich znaczenie zrozumiałem dopiero gdy poczytałem kilka książek o programowaniu gdzie opisane są jezyki naprawdę obiektowe


W dobrym języku obiektowym deklarujac jakas funkcje lub metode mozna wymusic by podany argument byl danego typu: byl daną klasą lub implementowal dany interfejs lub rozszerzal daną klase abstrakcyjną.

Spojrz na ten kod:

[PHP] pobierz, plaintext 
class pan_domu {
	public function nakarm_zwierze_miesozerne($zwierze) {
		$jedzenie = new Mieso();
 
		$zwierze->je($jedzenie);
	}
 
	public function nakarm_zwierze_roslinozerne($zwierze) {
		$jedzenie = new Salata();
 
		$zwierze->je($jedzenie);
	}
}
[PHP] pobierz, plaintext 

Wiec jest sobie jakis czlowiek, pan domu, ktory moze karmic swoje zwierzeta.

I teraz kod ktory uzyjemy do karmienia zwierzecia (kota):

[PHP] pobierz, plaintext 
$zwierze = new Kot();
 
$pan = new pan_domu();
 
$pan_domu->nakarm_zwierze_miesozerne($zwierze);
[PHP] pobierz, plaintext 

Wszystko jest pieknie, ale nie masz zadnej kontroli nad tym czy zwierze, ktore probujesz nakarmic je mięso.

OK, wlasnie sobie myslisz: jak to nie maz? Przeciez widze wyraznie co napisalem. Utworzylem kota z jakiejs tam klasy i go karmie miesem.

To jest zupelna prawda pod warunkiem, ze to ty jestes autorem klasy Kot(), ktorej specjalnie tu nie napisalem i wewntarz tego kota sa napisales metode je(), ktora wywoluje metode gryzie(), potem trawi() i dokladniej trawi_mieso() (zakladamy ze zwierz. roslinozerne beda mialy zamiast tego trawi_rosliny()) i tak dalej.

Jednak w warunkach naturalnych nad kodem pracuje sie w wiele osob. To ktos inny dostarczy klase Kot. Mozesz oczywiscie przejrzec jak ta klasa w srodku wyglada i jesli cos jest nie tak odeslac ten kod do wspolpracownika by go poprawil. Ale jesli pracujecie nad funkcją obslugującą Zoo zajmie ci to wieki zanim przejrzysz tak wszystkie zwierzeta, prawda?

I teraz pojawia sie polsrodek w postaci interfejsu. Tworzysz interfejs Zwierzeta_Miesozerne w ktorym definiujesz co taki zwierzak musi umiec:

[PHP] pobierz, plaintext 
interface Zwierzeta_Miesozerne {
	public function je();
	private function gryzie();
	private function trawi();
	private function trawi_mieso();
}
[PHP] pobierz, plaintext 

I pieknie. teraz tylko mowisz wszystkim wspolracownikom, twórcom zwierząt by ich zwierzeta implementowaly ten interfejs.

Zaczynasz juz lapac? Czekaj, to jeszcze nie wszystko

oczywiscie nadal musisz przegladac dostarczony kod czy on implementuje ten interfejs, prawda? O wiele mniej roboty, ale nadal jest robota.

Tu z pomocą przychodzi ostatnia wlasciwosc takich kontrukcji: wymuszanie typu parametrow. Przepisz swoj kod z samego poczatku mojego wyjasnienia tak by linijka:

[PHP] pobierz, plaintext 
public function nakarm_zwierze_miesozerne($zwierze) {
[PHP] pobierz, plaintext 

wygladala:

[PHP] pobierz, plaintext 
public function nakarm_zwierze_miesozerne( Zwierzeta_Miesozerne $zwierze) {
[PHP] pobierz, plaintext 

Takie cos wymusza by przekazane zwierze implementowalo dany interfejs. Jesli tak nie bedzie, PHP zwroci blad typu i po prostu calosc nie bedzie dzialac. Zatem juz nie musisz kodu przegladac: jesli programista cie nie poslucha, kod zwyczajnie nie bedzie dzialac.

Podsumowujac: tak jak ci to wyzej napisano, interfejsy i abstrakcje to jest rodzaj "umowy" w kodzie, umowy miedzy programistami tworzącymi różne fragmenty kodu, umowy dzieki ktorej zaden programista nie musi zagladac do srodka kodu stworzonego przez innego programiste.

kkarpieszuk wszystko fajnie, ale uargumentuj co masz na myśli mówiąc, że "one są niemal niepotrzebne w starszych wersjach PHP". Sorry ale co takiego 7 zmieniła w stosunku do 5?

Ok możemy zwracać konkretny typ i dodali obsługę skalarów, ale to niczego tutaj nie zmieniło.

@com w trakcie pisania doszedlem do tego samego, ale juz nie wykasowalem

w 5 brakuje mi jeszcze deklaracji zwracanych danych, ale ja juz siedze na 7 wiec problemow nie mam

Do autora tematu

Pytasz o znaczenie rzeczy, na temat których powstalo wiele ksiazek. Nie oczekuj ze ktokolwiek tutaj wyjaśni Ci sens. Zamiast ciągnąc temat, polecam Ci książke PHP Objects, Patterns and Practice edycje 3. Jak ja przeczytasz to zrozumiesz ze na ten moment nie masz bladego pojecia o programowaniu obiektowym. Zrozumiesz ze oop to prawdziwa sztuka, a nie tępe napisanie kilku klas - co kazdy potrafi. Pózniej wrocisz pamiecia do tego postu i sam z siebie bedziesz sie smial.

Jesli ludzie kierowali by sie zasadą ,,po co'' to do niczego bysmy nie doszli. Jesli nadal bedziesz szedl na latwizne to nigdy nie bedziesz dobrym programista - w sumie z korzyscia dla mnie bo im mniej konkurencji tym ja wiecej zarobie ; )