Revisione del mio design OOP per un semplice gestore di password

Naviga le tue risposte
2

Scriverò un semplice gestore di password, che memorizzerà i miei account crittografati. Ecco la descrizione delle classi,
LoginManager: questa classe sarà responsabile dell'autenticazione dell'utente, poiché i dati sull'harddrive saranno crittografati, riuscirà solo se i dati verranno decodificati correttamente, la prima riga del file di dati sarà [DECRYPTED], in modo che il programma è in grado di capire che i dati vengono decodificati con successo e consentono all'utente di accedere all'interfaccia utente. Dependecies:

  • DataChecker
  • CryptographyManager
  • StorageManager
  • UserInterface

UserInterface - Questa classe sarà responsabile della modifica, ricerca, visualizzazione e aggiunta di dati (account). Dependecies:

  • DataManager

DataManager - La responsabilità di questa classe è di gestire i dati, conterrà una tabella ad albero o hash dei dati. Deve essere in grado di cercare, modificare e aggiungere nuovi dati alla struttura dati. Dependecies:

  • Dati

Dati - Questa classe contiene i dati suddivisi in campi: ID, accout, commenti, password. Dovrebbe fornire un incapsulamento adeguato.

DataChecker - La responsabilità di questa classe è di verificare che la prima riga del file specificato sia [DECRYPTED], detta in altro modo per verificare se i dati sono decodificati con successo e crittografati (prima di chiudere il programma il file deve essere crittato ).

StorageManager - Questa classe è responsabile della lettura e scrittura dei dati dal disco.

CryptographyManager: questa classe è responsabile della memorizzazione dell'algoritmo di crittografia Dependecies:

  • CryptographyAlgorithm

CryptograpghyAlgorithm - Questa è l'interfaccia per diversi algoritmi di crittografia, ogni classe dovrebbe implementare metodi per crittografare e decodificare.

Ed ecco il diagramma UML:

Penso di aver reso questo disegno complicato. Il programma non è così complicato da utilizzare qualsiasi schema di progettazione, quindi ho cercato di seguire i principi solidi. Quello che mi infastidisce di più è che CryptographyManager sembra inutile. Vorrei sapere se sto violando i principi SOLID.

    
posta nameLess 25.09.2016 - 19:13
fonte

1 risposta

1

O alcuni importanti concetti SOLID mancano qui o alcuni concetti UML sono.

Prima di tutto, imposta un vocabolario:

anotherchris.net: umlcheatsheet

Fammi analizzare il diagramma.

Per ora sto semplicemente prendendo il testo nelle scatole come Vangelo e cercando di riconciliarlo con quello che le frecce mi dicono. Non sono d'accordo l'un l'altro.

  1. Freccia indietro, UserInterface non ha LoginManager o nemmeno sa che esiste
  2. Quando si collegano molti oggetti in uno provate a farlo insieme
  3. Tipo di freccia indietro e sbagliato <|--- non è per l'associazione ...
  4. ---> è
  5. Qual è il punto di avere queste interfacce anche se parli direttamente con le implementazioni? Scambia queste colonne.
  6. Come 5
  7. Essere schizzinosi, poiché AES non è uno di LoginManager's 4 cose che non mescoliamo visualmente mescoliamole con loro. Spostando le due caselle UserInterface da qualche parte sopra CrytographyManager lo pulisce bene.
  8. DataManager ha una associazione unidirezionale con Data che è stata persa.

Inoltre, le interfacce e le implementazioni non dovrebbero avere lo stesso nome. Alla gente c # piace mettere un prefisso I su ogni interfaccia. Altri preferiscono un suffisso 'Default' se c'è solo un'implementazione o ancora qualcosa di significativo.

Infatti, non vedo quale sia il beneficio di queste singole implementazioni in questo diagramma. Non mostrano alcuna scelta comportamentale come farebbero se ci fossero più implementazioni. Loro solo ingombrano. Anche se hai intenzione di farlo in questo modo, mostrarmi qui non aiuta.

UserInterface - This class will be responsible for editing, searching, viewing and adding data(accounts). Dependecies:

È qui che si nascondono molti problemi reali.

In che modo si tratta di un'interfaccia utente? Nessun utente è stato menzionato nel design di questa classe. Mi sembra un po 'di DataHandler per me.

Inoltre, in che modo UserInterface impara di DataManager ? Non hai qualche hijink localizzatore di servizio o statico globalmente pianificato, vero? Perché non è DataManager nel costruttore?

Soprattutto, cosa fa veramente UserInterface che gli altri oggetti dati non fanno?

    
risposta data 25.09.2016 - 21:55
fonte

Leggi altre domande sui tag

Come mantenere una struttura di database quando ci sono più istanze del DB? Controlla se i messaggi speciali ricevuti dal flusso di dati