In alcuni contesti di IOC, potrebbe essere richiesto il costruttore di un oggetto immutabile polimorfico nella sua interfaccia?

In un contesto OOP, avere un costruttore in un'interfaccia non ha senso: il tipo concreto - che sarebbe necessario per costruire un'istanza di un tipo - non è noto agli utenti di un'interfaccia. Tutto ciò che un consumatore sa è che un determinato oggetto implementa quell'interfaccia e può essere inviato a vari messaggi.

Tuttavia, non tutta la programmazione è orientata agli oggetti. Quando si usano tecniche come generici o modelli, stiamo usando interfacce / tipi / tratti / concetti per non vincolare oggetti , ma per vincolare tipi . Richiedere che un tipo offra un particolare costruttore ha perfettamente senso. In effetti, alcuni linguaggi (come Rust o Haskell) non hanno un concetto simile di "costruttore", ma solo funzioni ordinarie che capita di restituire un'istanza di quel tipo - e consentono a tali funzioni non di istanza di far parte di un interfaccia.

Di solito non è possibile scrivere un'interfaccia che richiede che un oggetto sia immutabile. Mentre un'interfaccia potrebbe non offrire alcun mutatore, potrebbe fornire metodi aggiuntivi che cambiano il suo stato. Pertanto non sono sicuro che il tuo esempio di IOC possa essere realizzato in un linguaggio tipico.

Riguardo l'esempio di iniezione di dipendenza nella domanda, una soluzione tipica è non iniettare una classe con il suo costruttore, ma iniettare una funzione di fabbrica arbitraria che sia in grado di costruire un oggetto adatto. Questa funzione di fabbrica può avere molte dipendenze possibili ma non deve usarle, permettendoci così di astrarre la firma specifica del vero costruttore. Ad esempio:

function make_A($dep_a, $dep_b) {
  return new ImplementationA($dep_a);
}
function make_B($dep_a, $dep_b) {
  return new ImplementationB($dep_a, $dep_b);
}

// in some configuration:
$DI_CONFIG['SomeInterface'] = make_A;  // or make_B

// in the DI container:
$dep_a = ...;  // resolve dependency
$dep_b = ...;
$some_instance = $DI_CONFIG['SomeInterface']($dep_a, $dep_b)

L'interfaccia potrebbe non conoscere il costruttore, ma la classe di implementazione concreta fa e può creare nuovi oggetti immutabili, se necessario. Considera un'interfaccia come (in Scala):

trait Immutable {
    def increment: Immutable
}

Qui, increment restituisce un altro oggetto Immutable . Puoi implementarlo in questo modo:

class Count(count: Int) extends Immutable {
    def increment: Immutable = new Count(count + 1)
}

Count conosce il proprio costruttore, quindi anche se il costruttore non fa parte dell'interfaccia, può ancora essere utilizzato per implementare parti dell'interfaccia. Allo stesso modo, una classe factory potrebbe conoscere internamente su tutti i costruttori per le classi concrete che può costruire.