Aggiunta di metodi in aggiunta a un'interfaccia

Supponendo che do sia ancora un nome preciso (e coerente con l'altro metodo do ), non vedo alcun problema nel fare ciò. In realtà, è un modello abbastanza comune.

Come Oleksi menzionato , è un modello comune. Ma assicurati che non sia pubblico. Se vuoi renderlo pubblico, aggiungi meglio all'interfaccia stessa.

Penso che potresti non capire appieno quale sia lo scopo della programmazione delle interfacce. La ragione per farlo è che qualsiasi codice client può ottenere un oggetto di tipo IThing e sapere cosa fare con esso. Quindi non ci sarebbe modo per il metodo sovraccarico di essere mai chiamato da un client la cui intera conoscenza di ThingImpl è che è un IThing .

Detto questo, considero spesso la mia Applicazione come un sistema simile a ordinare qualcosa da Amazon.com. Ordino qualcosa e un IThing è fatto in fabbrica. Il codice di cablaggio nell'applicazione è abbastanza soddisfatto di un IThing , in quanto il carrello UPS è dotato di una scatola. Tuttavia, quando la scatola arriva a destinazione, mi interessa ancora una volta che ciò che è nella mia scatola è esattamente quello che ho ordinato (quindi controllerò l'inventario per assicurarmi che il contenuto della scatola sia specificamente quello che mi aspetto). Più letteralmente, il codice dell'endpoint controllerà il tipo di implementazione di IThing prima di tentare di usarlo.

Sembra che il tuo codice sia la fabbrica. In casi come questo, in realtà creerò solo due Fabbriche, una che sa come impostare il parametro su true e l'altra che sa come impostarla su false. Le fabbriche verranno archiviate in una sorta di hash e richiamate in base alle specifiche di quello che sto creando (ad esempio, potrei avere un registro di fabbriche che creano oggetti dati di domande in base alle informazioni che ottengo da un file XML, e Estrarrò una particolare factory dall'hash in base al tipo di domanda).