Qual è il modo migliore per affrontare questo problema nella progettazione orientata agli oggetti? - astrazione di dischi virtuali

4

Sto scrivendo un programma che manipola dischi virtuali criptati e unità flash crittografate (ad esempio, importazione di dischi nella mia applicazione, montaggio / smontaggio, modifica delle password ecc.). Sono ancora nuovo nella progettazione orientata agli oggetti, quindi ho riscontrato il seguente problema.

Ho identificato tre tipi di dischi :

  • Disco memorizzato in un file (disco virtuale) su un disco rigido (posizione fissa)
  • Disco memorizzato in un file (disco virtuale) su un dispositivo rimovibile (ad esempio, unità flash, il percorso assoluto può cambiare)
  • Unità flash crittografata (come sopra ma memorizzata direttamente sul dispositivo, quindi nessun percorso file)

Le operazioni che devo eseguire su questi dischi sono il montaggio, lo smontaggio, il controllo della presenza sul computer e la modifica della password. Il problema principale che ho è con le differenze (e somiglianze) nella memorizzazione della loro posizione (il file su un disco rigido può fare solo con un percorso file assoluto, il dispositivo crittografato può fare con un ID dispositivo, il file su un dispositivo rimovibile ha bisogno di entrambi ID dispositivo e un percorso relativo sul dispositivo).

Ho trovato soluzioni multiple finora ma nessuna delle quali mi è piaciuta. C'è un modo preferito per farlo? O sto pensando a questo nel modo sbagliato?

Modifica : le soluzioni che ho trovato finora:

Soluzione 1:

  1. Creazione di una base disco astratta con metodi astratti per le operazioni di cui ho bisogno (e alcuni dati sul montaggio comune a tutti i dischi).
  2. Dalla classe base derivano una classe PhysicalDisk e una classe VirtualDisk. VirtualDisk memorizza la sua posizione come percorso fisso (stringa) e PhysicalDisk memorizza la sua posizione in una classe RemovableDevice (contiene un ID dispositivo, flag di stato, ecc.). Entrambe le classi implementano le operazioni dalla classe base rispetto a come viene memorizzata la loro posizione.
  3. Dalla classe VirtualDisk ho quindi derivato una classe RemovableVirtualDisk, che aggiunge una classe RemovableDevice come membro e reimplementa alcuni dei metodi parent per tenere conto di questa modifica.

Il problema è che i metodi implementati nelle classi derivate sono molto simili, variando principalmente per quanto riguarda la posizione in cui è archiviato il disco.

Soluzione 2:

  1. Creazione di una classe per tutti i tipi di dischi, ad es. EncryptedDisk, che quindi memorizza la posizione del disco utilizzando il polimorfismo, in una classe DiskLocation astratta. Da DiskLocation I derivano una classe FileOnFixedDevice (per i dischi virtuali) e una classe RemovableDevice (per le unità crittografate). Da ciò deriva anche una classe FileOnRemovableDevice (per dischi virtuali su unità rimovibili).
  2. Le classi implementano un metodo GetSystemLocation () e un metodo IsDeviceInSystem (), che vengono quindi utilizzati uniformemente nella classe EncryptedDisk per tutti i tipi di dischi.

Il problema che ho riscontrato con questa soluzione è che eseguo controlli per la disponibilità dei dispositivi anche quando non ha senso (dischi su hard disk). Potrei anche aver bisogno di avere alcune informazioni specifiche sulla posizione del disco in futuro, non solo oggetti polimorfici che potrebbero essere qualsiasi cosa.

Forse il design ottimale è da qualche parte nel mezzo? O un approccio diverso potrebbe risolvere i miei problemi?

    
posta Adam Smejkal 20.03.2015 - 19:08
fonte

1 risposta

2

The problem is that the implemented methods in derived classes are very similar, varying mostly in respect to how the location of the disk is stored.

Questo non è un problema. Il punto di progettazione orientata agli oggetti non è quello di ridurre la quantità totale di codice calcolando il codice comune nei metodi della superclasse. Il punto di progettazione orientata agli oggetti è la corretta modellazione delle entità del mondo reale. Quindi, è perfettamente normale che molti dei metodi siano molto simili.

Se riesci a pensare a modi in cui puoi calcolare il codice comune dalle classi derivate e in nuovi metodi della superclasse, fallo solo se i metodi della superclasse hanno scopi ben definiti che in realtà hanno senso per la superclasse quando esaminati su proprio, senza alcuna conoscenza delle sue sottoclassi.

Entrambi gli approcci che hai descritto sembrano validi, quindi non so quale di essi preferisci, ma qualunque cosa tu faccia, cerca di mantenere il numero totale di classi (e la quantità totale di codice, se possibile) devi rappresentare il tuo modello il più piccolo possibile, perché è molto probabile che cambi quando ottieni una migliore comprensione della situazione, quindi più è piccolo, più sarà facile cambiarlo.

Alla luce di ciò, il primo approccio potrebbe essere preferibile, perché sembra più piccolo.

    
risposta data 20.03.2015 - 21:25
fonte

Leggi altre domande sui tag