Come gestire quando è necessario smaltire solo determinate classi derivate?

Question

Come gestire quando è necessario smaltire solo determinate classi derivate?

#1 da (4 voti)
#2 da (2 voti)

2

Sto cercando di costruire una struttura di oggetti in cui gli attori principali possano essere scambiati liberamente. Al momento l'ho fatto creando una classe base astratta da cui tutti i miei attori possono essere derivati. Un motivo chiave per l'utilizzo di una classe astratta su un'interfaccia era che c'era un piccolo bit di codice comune che tutte le classi derivate dovrebbero usare.

Il mio obiettivo è creare un sistema che possa essere facilmente esteso da altri sviluppatori (un giorno) che condividono alcune logiche comuni e che gli oggetti derivati possano essere interscambiati senza interruzioni.

Ho avuto alcuni problemi con il modo in cui ho progettato il sistema. Uno è che non è stato facile testare i consumatori del mio framework. Ma quello a cui sono più interessato a risolvere al momento è che alcune delle classi derivate devono implementare IDisposable perché contengono oggetti che devono essere eliminati.

La soluzione migliore che ho trovato al momento è che la classe astratta implementa IDisposable anche se non lo richiede e anche alcune delle altre classi derivate non lo richiedono. Mi rendo conto di avere alcuni problemi fondamentali con il modo in cui ho modellato i miei oggetti e sto cercando di trovare il modo migliore per farlo.

Tuttavia, sono ancora curioso di sapere qual è il modo migliore per implementare in modo condizionale IDisposable? Oppure ho solo un serio problema di progettazione che deve essere risolto e sto cercando di risolvere un problema che non sarà più un problema con il modello corretto?

object-oriented c# .net

posta Mike D. 19.04.2016 - 15:38

fonte

2 risposte

Leggi altre domande sui tag object-oriented c# .net

Perché il team di sviluppo di IntelliJ IDEA memorizza le sue dipendenze come jar (ad esempio JUnit) all'interno delle proprie cv? Test dell'unità / Come convalidare i campi privati di un oggetto appena creato?

score 4 · Answer 1

Non penso che sia irragionevole che la tua classe base astratta fornisca un'implementazione vuota dell'interfaccia IDisposable e che le sottoclassi implementino la loro implementazione come richiesto. Mi sembra un modello comunemente usato e capito.

score 2 · Answer 2

Il suggerimento di Brian Agnew è molto applicabile, ma mi piacerebbe sottolineare qualcos'altro:

Ho la sensazione che forse il actors (il comportamento plug-in che tu menti) sul tuo modello stia portando due responsabilità molto diverse. In alternativa, è possibile progettare il framework in modo che disponga di un meccanismo di registrazione separato, esclusivamente per le risorse disponibili, nello stesso modo in cui si consente la registrazione di actors . Giusto per chiarire, supponiamo che tu abbia attualmente la seguente classe:

class MyFramework {
   public void RegisterActor(Actor actor) {
     ...
   }
}

E che la classe base Actor (o interfaccia) assomiglia a questa:

abstract class Actor : IDispoable {
   ...
}

Potresti dividere le nozioni di actors e disposable resources cambiando l'uso del tuo framework per consentire ad entrambi di essere registrati separatamente, in questo modo:

class MyFramework {
  public void RegisterActor(Actor actor) {
    ...
  }

  public void RegisterResource(IDisposable resource) {
    ...
  }
}

Ciò ti consentirebbe di rompere l'interfaccia IDisposable dal tuo modello actor , dando comunque l'opzione all'implementatore della sottoclasse di avere entrambe le implementazioni nello stesso oggetto, se questo ha senso, in questo modo:

class SomeActorImplementation : Actor, IDisposable {
   ...
}

Con questo, lo stesso oggetto può essere inviato a entrambi i metodi RegisterActor e RegisterResource dell'oggetto quadro, ma non ne avrà conoscenza.