Apsraktna klasa sa svim implementiranim metodama, kad koristiti ?

[Peca]

ja sam baš skoro imao slučaj kada je za malo cela klasa mogla biti abstraktna (govorim naravno o PHP-u).
no, ispalo je da imam par funkcija koje mogu da delim sa potklasama.

trebao mi je dakle unikatan aplication interface - a potklase su bile tu jer su istu stvar implementirale preko dve različite PHP biblioteke - pa se kreirala potklasa u zavisnosti od toga koja je PHP biblioteka instalirana na sistemu.

svaki drugi koncept (koji ne bi išao preko abstrakcije) bi bio koncepcijski loš.

[jablan]

Originalno napisao japan

Jedno pet puta već čitam pokušavajući da shvatim tvoj argument, ali mi ne uspeva. Daj, molim te, objasni mi šta hoćeš da kažeš...

Hoću da mi neko objasni čemu služe apstraktne klase u dinamičkom jeziku kao što je PHP.

Primer:

Ti u PHP-u možeš da uradiš sledeće:

class Duck{
        function quack(){ echo "Quack\n";}
        function fly(){ echo "Flap, Flap\n";}
}
class Person{
        function __construct($name){$this->name=$name;}
        function quack(){echo "{$this->name} walks in the forest and imitates ducks to draw them\n";}
        function fly(){ echo "{$this->name} takes an airplane\n";}
}
 
function QuackAndFly($obj){$obj->quack(); $obj->fly();}
 
QuackAndFly(new Duck());
QuackAndFly(new Person("Jules Verne"));

Tj. ne postoji kompajler koji će da kaže koju klasu funkcija QuackAndFly mora da primi kao argument (isto važi i za npr. dodelu promenljivih, jedna ista promenljiva u jednom trenutku može držati instancu Duck, a u drugom instancu klase Person itd). Samim tim ne postoji obaveza programera da pravi klase u kojima kaže "e sad ovde će biti jedna metoda, ali neću sad da je implementiram, već će to morati da urade potklase", da bi zadovoljio kompajler, kao što postoji u statičkim jezicima tipa Jave. U Javi bi za gornji primer morao da napraviš parent apstraktnu klasu QuackableFlyableItem, koju bi onda Duck i Person nasleđivale, pa onda da kažeš da funkcija QuackAndFly prima argument tipa QuackableFlyableItem itd itd.

Dakle, interesuje me zašto je u PHP dodat feature koji je u statičkim jezicima tu samo kao nužno zlo, upravo zato što su statički?

Nadam se da sam jasniji.

[japan]

Iskreno, nisam nikad na apstraktne klase gledao kao na mehanizam za puko zadovoljenje kompajlera u ovakvim slučajevima, već više kao na pogodnost koja omogućava da se konstrukt "implemetnts Interface, extends Base" svede na "extends AbstractBase".

A što se tiče tvog primera, ako se ne varam, ni u Javi ti ne treba apstraktna roditeljska klasa, tj. dovoljno je da ona postoji, ne mora da bude apstraktna, i to će da radi, i kompajler se neće buniti, sve dok obe klase koje je nasleđuju sadrže potrebne metode. A ako hoćeš da se zaštitiš od "zloupotreba" tipa prosleđivanje ovoj QuackAndFly() f-ji objekta koji nema neki od potrebnih metoda, e tu u jednačinu ubacuješ apstraktnu klasu, i tu onda nema veze da li je jezik statički ili dinamički, i za jedne i za druge važi isto - moraju da implementiraju sve metode...

[jablan]

Originalno napisao japan

više kao na pogodnost koja omogućava da se konstrukt "implemetnts Interface, extends Base" svede na "extends AbstractBase".

Ali upravo to i pitam, zašto je potrebno da AbstractBase bude nešto specijalno, da zahteva specijalni keyword i specijalan thread na DPT, zašto ne može da bude obična PHP klasa koju ćeš nazvati AbstractBase ako ti baš toliko znači da to nešto bude "apstraktno".

Što se tiče primera, u Javi je neophodno da 1) postoji roditeljska klasa, i 2) da roditeljska klasa ima navedena dva metoda. Keyword abstract ti omogućava da te metode ne moraš da implementiraš (pišući prazne brejsove ili dižući exception), po cenu da samu parent klasu ne možeš da instanciraš.

PHP i drugi dinamički jezici već imaju tu pogodnost da 1) ne moraš da imaš parent klasu, a ako baš hoćeš da je imaš, 2) ne moraš da navodiš neimplementirane metode i 3) možeš da sprečiš njeno instanciranje na druge načine koji ne zahtevaju dodatno bloatovanje ionako već punačke sintakse.

[japan]

Pa šta znam, ja sam na to gledao kao na feature, kada imaš potrebu da za neku familiju odrediš zajedničku osnovu, a ne kao na bloat.

U tom slučaju jeste, ne mora da postoji, ali onda ne mora da postoji ni u statičkim jezicima, jer sve to može isto tako da se izvede upotrebom interfejsa, override-ovanja metoda, i nekom tehnikom za zabranu instanciranja.

[webarto]

@jablan

namespace Dpt;

abstract class Database
{
  protected $link;
  abstract public function query(string $query);
}

class Mysql extends Database
{
  public function query(string $query)
  {
    return mysql_query($query, $this->link);
  }
}

class Pdo extends Database
{
  public function query(string $query)
  {
    return $this->link->query($query);
  }
}

Kako misliš...

a.) zabraniti instanciranje?
b.) forsirati implementiranje metoda?

namespace Dpt;

class Database
{
  public function __construct()
  {
    trigger_error('Not allowed', E_USER_ERROR); 
  }
}

class Mysql extends Database
{
  public function __construct()
  {
    
  }
  
  function query()
  {
    var_dump(func_get_args());
  }
}

(new \Dpt\Mysql)->query('Hello');

Apstraktna klasa je klasa + interface, koja se uz to ne može instancirati, ima svoju svrhu, ali mislim da se mnogo puta koristi u pogrešne svrhe.

Tvoj mi primjer nije jasan, jesi li mislio na ovo:

function QuackAndFly(Duck $obj){$obj->quack(); $obj->fly();}

Možeš ti u recimo PHP da uradiš sve, ali ne mora da znači da trebaš, nije ni Java sjajan primjer.

[jablan]

Originalno napisao japan

ne mora da postoji ni u statičkim jezicima, jer sve to može isto tako da se izvede upotrebom interfejsa, override-ovanja metoda, i nekom tehnikom za zabranu instanciranja.

Kako ne mora da postoji ni u statičkim jezicima? Ti u interfejsu ne možeš da implementiraš nijednu metodu, dakle interfejsi nisu zamena za (apstraktne) klase. Možeš, kao što sam ranije rekao, da napraviš običnu klasu sa praznim metodama, ali je ružno, ima puno boilerplatea (praznih metoda ili dizanja exceptiona itd). Apstraktne klase itekako imaju smisla u statičkim jezicima.

Ono što mi nije jasno je šta ti njima dobijaš u dinamičkom jeziku. Obične parent klase bez deklarisanih metoda sasvim dobro rade posao, zar ne?

@webarto: Upravo tako. S tim što je bacanje exceptiona u Database konstruktoru skroz opciono, jer ti praktično ništa ne dobijaš time, jedino pišeš kod za nekog morona koji bi probao da instancira Database klasu. U statičkim jezicima to opet ima smisla, jer će se greška pojaviti u compile timeu, tj. neće moći da se program iskompajlira ako neko napiše "new Database". U PHPu (ako se ne varam, ispravite me ako grešim), čak i da koristiš apstraktnu klasu, greška bi iskočila u runtimeu, tako da i ta prednost apstraktne klase koju imaš u Javi ovde ne postoji.

Takođe je i sama svrha postojanja parent klase diskutabilna (u tvom primeru nema smisla, ali hajde da pretpostavimo da te dve klase zaista imaju neku zajedničku funkcionalnost).

Sve u svemu, PHP i ostali dinamički jezici su praktično srećni zato što programer nema potrebu da piše puno koda samo da bi zadovoljio kompajler. Zato me čudi što se veštački dodaju featuresi iz statičkih jezika iako nemaju smisla i praktično ukidaju prednosti koje dinamički jezici imaju. To bi bilo kao da atletičar navuče bocu s kiseonikom od 10 kila pre trke samo zato što je video da ronioci to rade.

[Djuki]

Originalno napisao jablan

Samim tim ne postoji obaveza programera da pravi klase u kojima kaže "e sad ovde će biti jedna metoda, ali neću sad da je implementiram, već će to morati da urade potklase", da bi zadovoljio kompajler, kao što postoji u statičkim jezicima tipa Jave.

Postoji

PHP kôd:

class Vizija
{
    abstract function definisiViziju();
}

class Birokratija extends Vizija
{

} 


Klasa Birokratija je u obavezi da implementira metodu definisiViziju inače će interpreter prijaviti grešku:

PHP kôd:

Fatal error: Class Vizija contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Vizija::definisiViziju) 


Što se tiče primera sa Patkom i Čovekom očigledno je da oni treba da implementiraju u najmanju ruku jedan isti interfejs (samo u tvom primeru, jer ako bismo sada išli do kraja rekli bismo da je potrebno primeniti adapter patern, jer je odličan za ovu imitaciju patke).

Webarto je krenuo u pravom smeru.

PHP kôd:

interface LeteciObjekat
{
    public function quack();

    public function fly();
}
function QuackAndFly(LeteciObjekat $obj){$obj->quack(); $obj->fly();} 


[webarto]

@djuki

Ako je i jedna metoda abstract onda i klasa mora biti abstract, za to je izbacilo grešku a ne za ono što si mislio.

abstract class Vizija
{
    abstract function definisiViziju();
}

class Birokratija extends Vizija
{

}

Fatal error: Class Birokratija contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Vizija::definisiViziju)

@jablan mrsko mi je bilo pisati, ali zamisli da ima smisla Po meni ima smisla to što govoriš, i stvari kao goto i traits su implementirane, ali abstract ipak ima svoju funkciju.

[Djuki]

@webarto

U pravu si da mora biti abstraktna i klasa. Ipak važan je deo što jablan kaže da ne možemo "naterati" naslednike da implementiraju metode. Možemo naravno. Ovo što pišem radi u 5.2 verziji.

PHP kôd:

abstract class Vizija
{
    abstract function definisiViziju();
}

class Birokratija extends Vizija
{

}

$borokratija = new Birokratija(); 


ovde dobijamo grešku

PHP kôd:

Fatal error: Class Birokratija contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Vizija::definisiViziju)