Ridondanza causata dal polimorfismo

3

Ho due chat room, una ha un comportamento amministrativo e l'altra no. Ho preso in considerazione tutto il codice comune in una chat room di base, ma il comportamento AdministerChatroom l'ho estratto in un'interfaccia chiamata IAdministrable e si trova nella classe della chatroom di base.

Il mio problema è che, poiché l'interfaccia si trova sulla classe base, che consente il comportamento su polimorfico, la classe NonAdministratableChatroom chatroom deve implementare tale comportamento anche se non farà nulla.

Ho visto alcuni sviluppatori mettere l'interfaccia su una sola sottoclasse: la classe che ha il comportamento, in questo caso il metodo AdministerChatroom , e quando viene utilizzata una chat room, controlla semplicemente l'esistenza di IAdministrable interfaccia, qualcosa come if(Chatroom is IAdministrable){ // do something } , che sembra una violazione del principio "non chiedere".

Mi sembra di avere due scelte: mi attengo al modello di strategia polimorfica, o collaudo l'istanza per un'interfaccia; il primo sembra preferibile, ma mi chiedo se ci sono altre opzioni?

Il codice per le classi è il seguente:

public interface IAdministrable
{
    void AdministerChatroom();
}

public abstract class BaseChatRoom : IAdministrable
{
    public void Close()
    {
    }

    public abstract void AdministerChatroom();
}

public class AdministrableChatroom : BaseChatRoom
{
    private readonly Administrator _administrator;

    public AdministrableChatroom(Administrator administrator)
    {
        _administrator = administrator;
    }

    public override void AdministerChatroom()
    {
        _administrator.DoSomethingSpecial();
    }
}

public class NonAdministratableChatroom : BaseChatRoom
{
    public override void AdministerChatroom()
    {
        // do nothing as this is not administrable
    }
}

public class Participant
{

}

public class Administrator : Participant
{
    public void DoSomethingSpecial()
    {
        // implement something special here
    }
}
    
posta nickbw 01.09.2014 - 06:05
fonte

1 risposta

7

Mi infastidisce che l'educazione alla progettazione orientata agli oggetti si concentri quasi esclusivamente sulla progettazione di gerarchie di oggetti e trascuri quasi completamente la struttura dell'altro lato, spesso più ampio, dei programmi orientati agli oggetti: il codice chiamante.

La risposta è di mettere l'interfaccia su una sola sottoclasse e strutturare il codice chiamante in modo che tutto il codice chiamante non si preoccupi di quale sottoclasse agisce contro, o sa sempre che implementa la tua interfaccia amministrabile.

In altre parole, ad un certo punto parte del tuo codice vorrà chiamare AdministerChatroom . Questo dovrebbe provenire da un altro metodo dell'oggetto AdministrableChatroom , o da un gestore di raccolta o evento da qualche parte che ha solo un riferimento a un IAdministrable . Se il tuo codice chiamante non è strutturato in questo modo, ha bisogno di refactoring. Se hai bisogno di aiuto con il refactoring, devi pubblicare ulteriori dettagli sul tuo codice chiamante.

    
risposta data 01.09.2014 - 07:11
fonte

Leggi altre domande sui tag