Metodi astratti vs variabili di istanza per oggetti riutilizzabili

Penso che i metodi astratti siano la scelta migliore. Se l'implementazione di queste proprietà non è qualcosa di cui le sottoclassi devono preoccuparsi, potresti anche volere che la classe base ne sia responsabile, cioè utilizzare i campi privati nella base classe con accessor pubblici e mutatori protetti:

public class SuperBaseClass {

    private int numberOne;
    private String stringOne;
    private String stringTwo;

    public int getNumberOne() { return numberOne; }
    public String getStringOne() { return stringOne; }
    public String getStringTwo() { return stringTwo; }

    protected void setNumberOne(String numberOne) { this.numberOne = numberOne; }
    protected void setStringOne(String stringOne) { this.stringOne = stringOne; }
    protected void setStringTwo(String stringTwo) { this.stringTwo = stringTwo; }

    public printStuff() {
        Log.i("IntAndTwoStrings", String.format("%i %s and %s", getNumberOne(), getStringOne(), getStringTwo()));
    }
}

Questo tipo di approccio fornisce un strong incapsulamento, ovvero la quantità di codice che può modificare direttamente i tuoi campi è ridotta al minimo.

L'approccio astratto alla classe costringe anche la classe estesa a "inizializzare" le variabili mentre con le variabili di istanza protette i valori predefiniti potrebbero essere facilmente usati portando a confusione / bug se non estesi.

IMHO un approccio migliore è usare la composizione ed evitare del tutto l'ereditarietà se si tratta solo di personalizzare alcuni campi. Dici "per ottenere le risorse dalla classe figlio", quindi fallo:

public class MyResources() {

private int numberOne;
private String stringOne;
private String stringTwo;

public int getNumberOne() {
    return numberOne;
}

public void setNumberOne(int numberOne) {
    this.numberOne = numberOne;
}

public String getStringOne() {
    return stringOne;
}

public void setStringOne(String stringOne) {
    this.stringOne = stringOne;
}

public String getStringTwo() {
    return stringTwo;
}

public void setStringTwo(String stringTwo) {
    this.stringTwo = stringTwo;
}
}

Quindi istanzia gli oggetti MyResources nelle classi e personalizzali come richiesto. Se hai ancora bisogno di avere una gerarchia di classi puoi avere il tuo oggetto risorsa nella classe base ed ereditarlo nelle classi figlie:

public abstract class SuperBaseClass {

protected MyResources resources;

public SuperBaseClass() {
    resources.setStringOne("Hello");
}

public class ReusedAppClass extends SuperBaseClass {

public ReusedAppClass () {
    super();
    resources.setStringOne("Hi");
}
}

Se tutte queste variabili sono proprietà della classe base e i bambini dipendono uniformemente da esse, dichiararle nella base è appropriato e aggiungere get / setter / accessor astratti sarebbe il modo per consentire ai bambini di massaggiare i dati come vedono in forma. Questo non è affatto eccessivo e OOP è progettato per esprimere questo tipo di relazioni.

Se ti accorgi che stai portando troppa quantità di questo tipo di dati alla classe base (o questi dati non sono universalmente comuni a tutti i bambini) allora potrebbe essere il momento di una più grande refactoring della classe base in un contenitore per altre classi di base più specifiche per organizzare la logica e il codice. Questo sarebbe un po 'più complesso ma consentirebbe un design più pulito, e con una buona nomenclatura uno più facile da seguire.

In entrambi i casi, devi prima analizzare che cosa ti aspetti di riutilizzare prima di cambiare le cose. La creazione di un framework riutilizzabile dal codice esistente finirà in un luogo molto diverso rispetto alla riorganizzazione dei dati e delle operazioni su quei dati per il riutilizzo dei moduli, ad esempio.