Responsabilità della classe base

Is it OK to have a base class with protected methods that deal with both activities and products, and have all 3 classes inherit from this base class?

No, non sarebbe male (tm).

Utilizza invece interfacce e composizione

public class EntityC : IActivities, IProducts
{
    private IActivities EntityA;
    private IProducts EntityB;

    public Activity GetActivity()
    {
        return this.EntityA.GetActivity();
    }

    public Product GetProduct()
    {
        return this.EntityB.GetProduct();
    }
}

Se crei una nuova classe base con tutte le funzionalità, diventerà sempre più grande finché non farà tutto.

Modifica post:

(1st) Means that I will have lots of instances to inject in constructor, for each separate helper method.

(2nd) Gives us the the same situtation as in my original question with inheritance, since I now have IActivityHelper inserted in ActivityA, and ActivityA needs to use only 2 methods out of 5 that it exposes.

Prima di tutto, non chiamarli 'Helpers'. Può sembrare un banale nitpick name, ma in realtà è la radice del problema.

Se chiami un Helper o un Manager di classe o qualcosa del genere, non hai idea di quali metodi dovrebbero essere utilizzati.

Disponi di un repository o di un filtro o di una ShoppingBag, quindi sai in quale classe deve essere inserito un nuovo metodo. Pensare al nome ti costringe a considerare la singola responsabilità di quella classe e ti fornirà classi di dimensioni ragionevoli con gruppi di metodi sensibili

Penso che quello che stai descrivendo sia FINE. Non c'è motivo per non farlo, ma ci sono alcuni problemi su come farlo.

Usi le interfacce per esprimere ciò che vuoi vedere esternamente, il tuo design. Tuttavia, puoi utilizzare ereditarietà per esprimere la condivisione del codice, soprattutto se utilizzi l'ereditarietà privata.

La chiave è definire INTERFACES per l'essenza di A-Activities e per l'essenza di B-Activities.

Quindi se hai un'implementazione di A e un'implementazione di B, che implementa tali interfacce.

E quindi puoi creare C, supportando le due interfacce. E se scegli di utilizzare l'ereditarietà privata o l'aggregazione, o qualche altro mezzo, è completamente la tua chiamata - qualunque sia la cosa più comoda.

interaceA {
  .... some methods;
};
interaceB {
  .... some methods;
};

ONE WAY:

class A1 : implement interaceA {
};
class B1 : implement interaceB {
};
class C1 : implements interface A, implements interfaceB {
  A a;
  B b;
 ....
};

UN ALTRO MODO RAGIONEVOLE:

spazio dei nomi privato {          class myhelper_: implementa A, implementa B {          ....          };    }

class A2 : implement interaceA , private::myhelper{
};
class B2 : implement interaceB, private::myhelper {
};
class C2 : implements interface A, implements interfaceB, private::myhelper {
 ....
};

EITHER way, hai catturato le tue due interfacce e il modo in cui le implementate è un dettaglio di implementazione nascosto.

Le interfacce e le classi base dovrebbero fornire una garanzia su come le istanze della tua classe possono essere interagite con. Essenzialmente, sono un meccanismo per il polimorfismo (in cui la classe base può anche fornire funzionalità e applicare restrizioni ai suoi discendenti). Questo non è ciò che stai cercando di ottenere qui, quindi non c'è motivo di preferire l'ereditarietà, quindi dovresti preferire la composizione.

La composizione ha almeno due vantaggi pertinenti a questo caso:

• Puoi farlo più di una volta
• Puoi scegliere quali parti degli oggetti composti usi effettivamente

Questo significa che puoi scegliere di avere un aiutante per le attività e un aiutante per i prodotti (dando uno a A, un altro a B, e entrambi a C). Oppure puoi scegliere di avere un aiuto per entrambe le attività e i prodotti (assegnandoli ad A, B, C), senza che nessuno al di fuori delle tue lezioni noti una differenza. Anche se la tua classe base non avrebbe un'interfaccia pubblica, avrebbe comunque effetto sui discendenti ipotetici di A, B e C, e ottenere l'accesso a quei metodi protetti significa che devi rinunciare a qualsiasi altra classe base che sarebbe utile.

Composition consente anche di usare l'iniezione delle dipendenze, che non è un'opzione quando si dipende dalla classe base. Tuttavia, puoi evitarlo se non ti è utile e creare internamente le istanze degli helper. Probabilmente sarà utile per testare se non altro. Se ti ritrovi a iniettare troppo, A, B e C probabilmente stanno facendo troppo. Se si desidera mantenere il codice client semplice, è possibile fornire costruttori predefiniti utilizzando le implementazioni di supporto predefinite.