Sto per scrivere una libreria Java. Fondamentalmente, questa libreria fornisce qualcosa di simile al suo utente:
interface Foo {
void doA();
boolean aWorked();
void doB(int value);
}
L'utente non dovrebbe implementare questa interfaccia (ovviamente). Pertanto, il codice utente sarà simile a questo:
Foo f = Library::SomeFactory();
if (someDecison()) {
f.doA();
if (!f.aWorked()) {
f.doB(21);
}
} else {
f.doB(42);
}
Posso assicurarmi che né le precondizioni né le post-condizioni dei metodi nell'interfaccia cambiano in futuro. Ma potrebbe esserci un nuovo metodo, ad esempio doC() .
Ora, varie risorse tra cui Documenti di Orcale suggeriscono che è sufficiente aggiungere questo doC() all'interfaccia precedente è una cattiva idea. Propongono diverse soluzioni estendendo l'interfaccia ...
interface Foo2 : extends Foo {
void doC();
}
... per far saltare il codice con schemi di comando e cosa no. Ma la ragione di supporto è sempre che "tutte le classi di implementazione devono essere cambiate". Nel mio caso questo non è un problema, poiché tutte le classi di implementazione sono "sotto il mio controllo" e dovrà essere modificato in entrambi i modi (quando c'è un doC() ).
Semplicemente aggiungere il metodo a Foo è davvero una cattiva idea? E se sì, perché? C'è qualcosa che non sto prendendo in considerazione qui? Il mio obiettivo principale è quello di non violare alcun codice utente scritto contro tale interfaccia.
// That's what I'm planning
interface Foo {
void doA();
boolean aWorked();
void doB(int value);
void doC();
}
Questa fonte supporta la mia sensazione che possa essere così semplice:
[..] If the method is added to a class (interface) which Clients are not allowed to subclass (to implement), then it is not a breaking change. [..]