Come gestire le "dipendenze inverse" tra classi con una corretta progettazione orientata agli oggetti?

Question

Come gestire le "dipendenze inverse" tra classi con una corretta progettazione orientata agli oggetti?

#1 da (1 voti)
#2 da (0 voti)

0

Sto cercando di apprendere una corretta progettazione orientata agli oggetti, con relazioni di classe ed evitando modelli di dominio anemici [1]. Sto creando un'applicazione per archiviare e recuperare informazioni su "cyber-attacchi". Ci sono cinque classi rilevanti per questa domanda:

Directory : la classe che rappresenta la raccolta dei dati indicati sotto
Gruppo : un gruppo di aggressori noti per essere correlati l'un l'altro
Hacker : una persona che effettua un attacco
Attack : un attacco di hacking, che include informazioni quali la gravità e il costo per riparare il danno
Tipo : gli attacchi sono classificati in questi tipi, ad esempio rifiuto del servizio, perdita di informazioni e così via. Questi tipi vengono inseriti dall'utente quando aggiungono un attacco.

I tipi di domande che gli utenti dell'applicazione chiedono sono:

Quali attacchi sono stati eseguiti da uno specifico hacker ? La risposta include informazioni sul danno di ciascun Attack , nonché su quale tipo ha.
per uno specifico gruppo , quali attacchi sono stati effettuati? Da chi, e quale è stato causato il maggior costo del danno?
Per uno specifico tipo , quali attacchi vengono fatti? Chi li ha fatti? Qual è il costo totale del danno?

Il modo ingenuo per risolvere questo problema includerebbe molte dipendenze circolari tra queste classi (ad esempio un hacker ha attacchi, ma anche gli attacchi hanno hacker e un tipo ha attacchi, ma un attacco ha anche un tipo e così via. ) Poiché le dipendenze circolari sono indesiderate, come risolverei questo con un design OO corretto?

object-oriented object-oriented-design class-design

posta kqr 08.01.2017 - 12:35

fonte

2 risposte

Leggi altre domande sui tag object-oriented object-oriented-design class-design

Progettazione per mantenere i dati del profilo utente locale sincronizzati con il server Database Architecture for SaaS application [closed]

score 1 · Answer 1

Quando gli oggetti hanno relazioni reciproche è importante definire quali sono le relazioni.

Quando dici "L'ingenuo modo di risolverlo includerebbe molte dipendenze circolari tra queste classi (cioè un hacker ha attacchi, ma anche gli attacchi hanno hacker e un tipo ha attacchi, ma un attacco ha anche un Tipo e così via). Poiché le dipendenze circolari non sono desiderate, come risolverei questo con un design OO corretto? "

usi la parola 'has' (o 'have') per entrambe le relazioni ma non definisci cosa significhi realmente. Sospetto che sarebbe più preciso dire:

L'attacco ha molti hacker
Gli hacker appartengono ad un attacco (chiave esterna attack_id)

Un determinato tipo di attacco ha molti attacchi
L'attacco ha un tipo di attacco (chiave esterna attack_type_id)

E quindi questi non sono riferimenti circolari, solo relazioni uno-a-molti.

score 0 · Answer 2

La mia prima reazione è di essere d'accordo con i commentatori. Ma se dobbiamo inserire i dati in un'applicazione, come potremmo strutturarli? Questo non è un tentativo di emulare un motore RDBMS; Ignorerò generalmente l'indicizzazione, la normalizzazione e l'algebra relazionale.

Meta Data

Per evitare riferimenti circolari, crea una classe di metadati per ogni classe: Hacker , Attack , ecc.

L'idea è di avere alcune informazioni (che definiscono "uguali" per esempio) mentre non istanziate una catena di riferimento, circolare o meno, di oggetti di dettaglio. E non perdere tempo, memoria, ecc. Quando non sappiamo ancora quali dettagli avremo bisogno.

Directory

Vedo questo come un'astrazione per un dato problema specifico. È il contesto che informerà su quali oggetti iniziamo e quali parti di una catena relazionale sono rilevanti. I riferimenti circolari ingenui possono essere evitati.

Inoltre, la codifica dovrebbe essere fatta consapevolmente per evitare catene di riferimento a circuito chiuso. Oltre il contesto, ancora da fare l'analisi del progetto può rivelare oggetti utili come sotto-parti delle presunte classi di dati: cioè Hacker , Attack , ecc.

Tutte le altre classi

Progettare ogni classe per includere tutte le proprietà appropriate per gli oggetti correlati. Quindi un Hacker ha una raccolta di Attacks .

L'analisi riflessiva potrebbe rivelare altre classi di componenti che possono essere utili ed è essenzialmente un vicolo cieco in una catena di relazioni. L'idea di una classe MetaData è un esempio.