Implicando il modo di costruzione di oggetti in interfaccia una buona pratica o no?

2

Per quanto ho capito, non sono già possibili linguaggi come Java , C# ecc. Perché il nome del metodo di definizione del costruttore in queste lingue deve essere uguale al nome della classe. Questo perché parlerò di PHP che la creazione del costruttore è più astratto dal nome della classe.

    public function __construct(Type1 $arg1, Type2 $arg2)
    {
        ...
    }

Fondamentalmente è possibile in PHP imporre construction in interface .

interface MyInterface {
    public function __construct(Type1 $arg1, Type2 $arg2);
    public function method1(Type3 $arg1) : Type3;
}

class MyClass implements MyInterface {
    public function __construct(Type1 $arg1, Type2 $arg2)
    {
        // Implementation.
    }
    public function method1(Type3 $arg1) : Type3
    {
        // implementation
    }
}

$object = new MyClass(new Type1(), new Type2());

Quindi fondamentalmente funziona. Se provo a definire un'implementazione di constructor diversa da interface , in pratica mi dà l'errore di tipo. È molto bello poter applicare il comportamento construction dell'oggetto con contract . Ma non ho visto questa pratica in altre lingue OOP cosa intendo Java è più OOP di PHP e domina il mondo OOP.

Quindi ecco alcune delle mie domande:

  1. Questa pratica ha alcune insidie che non vedo?
  2. Non c'è nulla di affermato in questa situazione in manuale o non l'ho ancora visto. Is this may be a harmless bug in PHP ?

Fondamentalmente quando passiamo attraverso l'ereditarietà se applichiamo la costruzione di una classe, essa impone anche i costruttori delle sottoclassi o ha la stessa firma. In caso contrario, è possibile solo il sovraccarico della funzione con i costruttori in PHP . Blocca semplicemente questo comportamento e può danneggiare l'estensibilità rispetto all'ereditarietà.

Ma anche final keyword punta a finalizzare l'ereditarietà applicandoli così per le classi finali e / o le classi che non vogliamo lasciare sovraccaricare i suoi costruttori? Pensi che sia una buona idea?

Mi piacerebbe sentire alcune idee e chiarimenti potrei abusare del comportamento che mi piace capire chiaramente.

    
posta FZE 29.09.2017 - 12:11
fonte

2 risposte

4

L'obiettivo dell'interfaccia è di astrarre l'implementazione.

Questo è il motivo per cui di solito non vedi i costruttori, i costruttori di una classe sono sul lato dell'implementazione.

Forzare un costruttore sta forzando fondamentalmente un dettaglio di implementazione, che potrebbe non essere quello che vuoi. Immagina un'interfaccia persistente, che sia implementazioni di XMLStorage e DatabaseStorage, è molto improbabile che abbiano bisogno di qualcosa nei comuni che si dirigono verso il loro costruttore (uno prende la cartella in cui si memorizza il file XML, gli altri prendono i parametri delle connessioni ).

Inoltre, questo non ha letteralmente alcun senso con un'interfaccia solo perché anche se puoi forzare il costruttore in MyInterface devi ancora chiamare new MyClass .

    
risposta data 29.09.2017 - 12:46
fonte
3

Ecco un'altra prospettiva. Con le interfacce si pongono le astrazioni trovate dalla decomposizione del dominio comportamentale. I metodi di interfaccia rappresentano le responsabilità dei concetti del tuo dominio, quindi le tue implementazioni concrete possono essere utilizzate polimorficamente. Ma il polimorfismo implica che un oggetto è già stato creato, quindi mettere un costruttore in un'interfaccia è semanticamente sbagliato.

    
risposta data 02.11.2017 - 09:01
fonte

Leggi altre domande sui tag