Perché PHP ha interfacce?

Il vantaggio principale delle interfacce in PHP è che le classi possono implementare più interfacce. Ciò consente di raggruppare classi che condividono alcune funzionalità ma che non necessariamente condividono una classe genitore. Alcuni esempi potrebbero includere la memorizzazione nella cache, l'output o l'accesso alle proprietà della classe in un determinato modo.

Nel tuo codice, puoi verificare se una classe implementa una determinata interfaccia invece di controllare il nome della classe. Quindi, il tuo codice funzionerà ancora quando verranno aggiunte nuove classi.

PHP fornisce alcune interfacce predefinite che possono tornare utili in varie situazioni: link .

MODIFICA - Aggiunta di un esempio

Se hai un'interfaccia chiamata MyInterface e stai lavorando con più oggetti di classi diverse che possono o meno condividere alcune funzionalità, le interfacce ti permettono di fare qualcosa del genere:

// Assume $objects is an array of instances of various classes
foreach($objects as $obj) {
 if($obj instanceof MyInterface) {
     $obj->a();
     $obj->b();
     $obj->c();
   }
}

PHP è tipicamente digitato, ma può essere strongmente digitato su cose come i parametri del metodo.

Considera il seguente esempio:

interface Car { function go(); }

class Porsche { function go() {} }

function drive(Car $car) {}

$porsche = new Porsche();

drive($porsche);

Il codice precedente verrebbe visualizzato:

Argument 1 passed to drive() must implement interface Car, instance of Porsche given

Le interfacce consentono di implementare il principio open-closed, mantenere una base di codice liberamente accoppiata e implementare molti dei migliori modelli di progettazione OOP.

Ad esempio, se una classe accetta un'altra classe come argomento:

class A {

    public function __construct(B $class_b) {
        // use class b
        $class_b->run();
    }
}

La tua classe A e la sua classe B ora hanno un accoppiamento stretto, e la classe A non può usare nessun'altra classe tranne B. Il tipo suggerimento fa sì che tu abbia il tipo corretto di argomento, ma ora ha cementato la relazione tra A e B .

Diciamo che vuoi che la classe A sia in grado di usare tutti i tipi di classi che hanno comunque un metodo run (). Questo è fondamentalmente (ma non del tutto) il modello di progettazione COMMAND. Per risolvere, si dovrebbe invece digitare suggerimento usando un'interfaccia invece di una classe concreta. B implementerebbe quell'interfaccia e sarà accettata come argomento per la classe A. In questo modo la classe A può accettare qualsiasi classe che utilizza tale interfaccia come argomento per il suo costruttore.

Questo tipo di codifica viene utilizzato nella maggior parte dei modelli di progettazione OOP e consente MOL più facili cambiamenti di codice in un secondo momento. Questi sono parte dei fondamenti della programmazione AGILE.

@pjskeptic ha una buona risposta e @ Kamil Tomšík ha un buon commento su quella risposta.

Il bello dei linguaggi digitati dinamicamente come PHP è che puoi provare a usare metodi sugli oggetti e non urlerò a meno che il metodo non sia lì.

Il problema con linguaggi tipizzati dinamicamente come PHP è che puoi provare a usare metodi sugli oggetti e ti urlerà quando il metodo non è presente.

Le interfacce aggiungono un modo conveniente di chiamare metodi su un oggetto sconosciuto e di essere certi che i metodi siano lì (non che siano necessariamente corretti o funzionanti). Non è una parte necessaria di una lingua, ma rende la codifica più conveniente. Permette agli sviluppatori OOP strongmente tipizzati di scrivere codice PHP strongmente tipizzato, che può quindi funzionare insieme a un codice PHP genericamente scritto da uno sviluppatore PHP diverso.

una funzione come:

foo( IBar $bar )
{
  $baz = $bar->baz();
  ...
}

è più conveniente di:

foo( $bar )
{
  if ( method_exists( $bar, 'baz' ) )
  {
    $baz = $bar->baz();
  }
  else
  {
    throw new Exception('OMGWTF NO BAZ IN BAR!');
  }
  ...
}

e il codice semplice e leggibile di IMHO è il codice migliore.

Sono completamente inutili se sei anatra-typer, in realtà quando scrivi anatra, è piuttosto fastidioso lavorare con librerie / framework che usano qualsiasi tipo di suggerimento.

Questo vale anche per tutti i tipi di meta-programmazione dinamica (metodi magici).

PHP è not liberamente o strongmente, ma digitato dinamicamente .

A proposito di interfacce, la prima cosa che dovresti chiederti è: quali sono i maggiori vantaggi delle interfacce?

In OOP, le interfacce non riguardano solo i tipi, ma anche il comportamento.

Poiché PHP ha anche una funzione di suggerimento , puoi usare le interfacce come faresti tu in un linguaggio puro, come Java.

interface File
{
    public function getLines();
}

CSVFile implements File
{
    public function getLines()
    {}
}

XMLFile implements File 
{
    public function getLines()
    {}
}

JSONFile implements File 
{
    public function getLines()
    {}
}

class FileReader
{
    public function read(File $file)
    {
        foreach($file->getLines() as $line)
        {
            // do something
        }
    }
}

Con l'implementazione dell'interfaccia PHP, puoi anche creare mock per classi astratte usando PHPUnit - e questa è una caratteristica infernale:

public function testSomething()
{
    $mock = $this->getMockForAbstractClass('File');

    $mock->expects($this->once())
         ->method('getLines')
         ->will($this->returnValue(array()));

    // do your assertions
}

Quindi, in pratica, puoi utilizzare l'applicazione compatibile SOLID in PHP utilizzando la lingua funzionalità, una delle quali è l'interfaccia.

Le interfacce sono utili per l'iniezione delle dipendenze molto più del calcestruzzo. Come esempio di barebone:

interface Istore { 
  public function save(); 
}

class Article_DB implements Istore 
{ 
  public function save($data) 
  {
    // do save to format needed.
  } 
}

class Article
{
   private $content;

   public function content($content)
   {
     $this->content = $content;
   }

   public function save(Istore $store)
   {
     $store->save($this->content);
   }
}

$article = new Article();
$article->content('Some content');

$store = new Article_DB();
$article->save($store);

Ora dì se le tue esigenze cambiano e vuoi salvare in un pdf. Potresti creare una nuova classe per quello scopo invece di inquinare la classe Article.

class Article_PDF implements Istore 
{ 
  public function save($data) 
  {
    // do save to format needed.
  } 
}


$article = new Article();
$article->content('Some content');

$store = new Article_PDF();
$article->save($store);

La classe Articolo ora ha un contratto che le classi che usa per salvare devono implementare l'interfaccia Istore. Non importa dove salva o come salva.

Puoi fornire oggetti reali "falsi" che implementano l'interfaccia. Potresti quindi testare una parte del tuo codice senza richiedere server reali, file system, socket, database ecc.

Probabilmente molte persone mi odieranno per aver risposto in questo modo, ma la soluzione ai tuoi problemi di digitazione può essere facilmente risolta con PHP. Sì PHP è tipicamente digitato in modo tale che i tipi vengano assunti di default, il che può causare alcuni problemi, specialmente nelle operazioni di confronto che sono la maggior parte dei problemi con le persone. Detto questo, PHP può essere altrettanto rigoroso di qualsiasi linguaggio strongmente tipizzato se si esegue il cast di quello che si sta utilizzando nel tipo che si desidera, e quindi si utilizzano operatori di confronto bit a bit. Ecco l'esempio più semplice che riesco a pensare a quello che sto dicendo:

$ myVar = (int) 0; $ myOtherVar = '0';

Il confronto ($ myVar == $ myVar) equivarrebbe a (bool) true

ma il confronto ($ myVar === $ myVar) sarebbe uguale a (bool) falso proprio come qualsiasi confronto "tipizzato"

Vorrei solo che gli sviluppatori smettessero di discutere di queste cose, se hai un problema con il modo in cui PHP funziona o vai in programma in java e live e lascia vivere, o usalo nel modo in cui farà ciò che vuoi a ... A cosa serve fare lo stesso per te? Ti do una scusa per girovagare tutto il giorno? Ti fanno sembrare migliore di qualcun altro? Beh, è bello che tu ti senta così bene con te stesso che sei disposto a far sembrare cattivo qualcun altro, ma in realtà è la tua preferenza e forzare le tue convinzioni su qualcuno in realtà li rende codificati in un modo in cui non sono constrongvoli causando tre cose:

1) Codificheranno la tua strada ma "disordinati" secondo i tuoi standard (pensa, hai mai visto un programmatore Java creare il loro primo programma PHP o viceversa? Sarà lo stesso per cambiare la loro metodologia o forse anche peggio. )

2) Troverete qualcosa di cui lamentarsi

3) Probabilmente ci vorrà più tempo per la produzione. E forse ti farà sembrare migliore a breve termine, ma la squadra nel suo insieme sarà peggio (ricorda che potresti programmare più lentamente di qualcun altro e questo non è necessariamente negativo finché il team incontra i risultati in un lasso di tempo ragionevole, ma forzare le tue abitudini a qualcuno che di solito si è comportato un po 'più velocemente potrebbe finire per rallentare l'intera squadra, quindi avere un aspetto peggiore in un flusso di lavoro molto impegnativo)

Personalmente preferisco scrivere codice PHP procedurale anche se posso e ho scritto programmi completi usando OOP in alcune lingue diverse. Detto questo, ho visto un buon codice OOP e un cattivo codice OOP, e un buon codice procedurale e un codice procedurale errato per questo ... Non ha davvero nulla a che fare con la pratica, ma con le abitudini che tu usi e anche in quel caso, molte cose sono i miei sentimenti interpretati ... questo non significa che parlerò male di quegli sviluppatori o di quelli che si vantano di "il mio modo è il migliore" BS, è giusto per me, e la compagnia per cui lavoro è molto soddisfatta del mio lavoro e ne sono orgoglioso. Ci sono dei motivi per stabilire uno standard, ma quello che includi nello standard che scegli è MOLTO importante ... Grazie per avermelo fatto togliere dal petto. Buona giornata.

1. Le interfacce fanno parte del paradigma OOP. Quindi è molto utile in molti casi quando si tenta di creare parti orientate agli oggetti o il proprio sistema.
2. Quindi. Perchè no? ; -)

Esempi: È necessario memorizzare i dati nella cache. Come? Esistono molti motori diversi per il caching, qual è il migliore? A chi importa se si dispone di un livello astratto con alcune interfacce ICacheDriver con un insieme di metodi come chiave, get, put, clear, ecc. Basta implementare ciò che è necessario nel progetto corrente e modificarlo quando ne hai bisogno. O semplice utilizzo di toString. Hai una serie di oggetti diversi e visibili. Implementate semplicemente un'interfaccia Stringable (che descrive il metodo toString [non ci sono realmente interfacce come quella in PHP, ma per esempio]) e solo l'interazione su tutto il vostro oggetto con (stringa) $ obj. C'è tutto quello che devi fare al posto di switch (true) {case $ obj isntanceof A1: "do 1"; rompere; ...}

Semplice. Quindi non c'è dubbio "Perché?". C'è "come usarlo meglio?". ;-) Buona fortuna.

La mia ipotesi.

PHP è utilizzato da molti programmatori entry-level , i programmatori entry-level sono insegnati java al college.

Dopo il corso di Programmazione 101 iniziano a tormentare Zend vogliono le funzionalità java perché questo è il modo in cui gli è stato insegnato a pensare, un pensiero alle tue condizioni (o la comprensione della digitazione anatra) è difficile, quando hai solo 20 anni.

Zend è pragmatico, è più facile aggiungere la funzione oltre a far finta di avere sempre ragione.
Anche questo acquista più utenti invece di farli andar via, quindi deve essere buono.

Un'altra istanza di questo processo? Le persone appena uscite da corsi .NET e Java desiderano anche Frameworks of Foundation Classes , ne parlano fino a quando Zend non supera il Zend Framework . Questo compra ancora più utenti. E così via ...

(l'unica funzione linguistica con cui il team di PHP ha ha lottato contro , nel corso degli anni è goto )