Esistono due tipi di associazioni tra oggetti o ci sono solo rappresentazioni diverse?

0

Ho trascorso un po 'di tempo a "risintonizzare" alcune delle mie conoscenze OOP e mi sono imbattuto in un concetto che mi confonde.

Diciamo che ho due oggetti. Un oggetto user e un oggetto account . Ritorna alle basi qui, ma ogni oggetto ha stato, comportamento e identità (spesso definito come oggetto entità).

L'oggetto user gestisce un comportamento puramente associato a un utente, ad esempio potremmo avere un metodo login(credentials) che restituisce se l'accesso è avvenuto correttamente o genera un'eccezione se non.

L'oggetto account gestisce un comportamento puramente associato a un account utente. Ad esempio potremmo avere un metodo checkActive () che controlla se l'account è attivo. L'oggetto account verifica se l'account ha una sottoscrizione aggiornata, controlla se ci sono dei flag di amministratore aggiunti che lo renderebbero inattivo. Restituisce se i controlli passano, o genera eccezione se non.

Ora qui sta il mio problema. Esiste chiaramente una relazione tra user e account , ma ritengo che ci siano effettivamente due TIPI di associazione da considerare. Uno che è guidato dai dati (esiste solo nei dati / stato degli oggetti e del database) e uno che è guidato dal comportamento (rappresenta una chiamata di oggetto ai metodi dell'oggetto associato).

Associazione basata sui dati

Nell'esempio che ho presentato, esiste chiaramente un'associazione dati tra user e account . In uno schema del database potremmo avere la seguente tabella:

-----------------
  USER_ACCOUNTS
-----------------
 id
 user_id
 ----------------

Quando istanziamo account e carichiamo i dati del database, ci sarà una variabile di classe contenente user_id . In sostanza, l'oggetto account contiene una rappresentazione intera di user a user_id

Associazione guidata dal comportamento

Le associazioni basate sul comportamento sono in realtà le dipendenze di un oggetto. Se l'oggetto A chiama i metodi sull'oggetto B, esiste un'associazione che va da A a B. A contiene una rappresentazione dell'oggetto di B.

Nel mio caso esemplificativo, né l'oggetto user né l'oggetto account dipendono l'uno dall'altro per eseguire le loro attività, vale a dire né i metodi di chiamata dell'oggetto sull'altro oggetto. Non esiste quindi alcuna associazione guidata dal comportamento tra i due e nessuno dei due oggetti detiene un riferimento a un oggetto all'altro.

Domanda

Il caso che ho presentato è puramente un caso di rappresentazione di entità? L'associazione tra user e account è sempre presente, ma è rappresentata in modi diversi?

es. l'entità user ha un'identità che può essere rappresentata in forme diverse. Può essere rappresentato come oggetto (l'oggetto user istanziato) o come un numero intero univoco dalla tabella utenti nei database.

Questo è un modo formalizzato per riconoscere differenti implementazioni di associazioni o ho perso completamente la testa?

Una cosa che mi infastidisce è come descriverei le differenze in UML o simili? O è solo un dettaglio di implementazione?

    
posta Gaz_Edge 04.09.2014 - 18:54
fonte

1 risposta

0

È un po 'difficile capire a fondo in cosa consiste effettivamente il problema :). Penso che tu stia un po 'mescolando alcuni concetti.

Rappresentazione di entità

In un primo momento, tutti i modelli che stiamo implementando sono solo una semplificazione di alcuni oggetti e ambienti reali. Il tuo utente di entità concettuale corrisponde ad un utente reale e contiene alcuni attributi che stiamo intrattenendo in base alle esigenze dell'applicazione. Quindi ci sono alcuni modelli che dobbiamo implementare.

Quindi, tutti gli utenti definiti dallo schema DB, definito dall'utente per classe e probabilmente definito dall'utente da una logica di presentazione, sono normalmente presenti in un utente del mondo reale. Si tratta solo di scopi di implementazione, dobbiamo archiviare, visualizzare e manipolare con l'utente.

D'altra parte diamo uno sguardo al principio di responsabilità singola. Ci dice di usare ogni classe o unità di programma solo per determinati bisogni. L'utilizzo di un singolo utente (classe o unità di programma) per esigenze di archiviazione e presentazione viola questi principi.

the user entity has an identity that can be represented in different forms. It can be represented as an object (the instantiated user object) or as a unique integer from the users table in the databases.

Quindi la risposta è sì.

Associazioni e dipendenze

Penso che sia più sulla terminologia che sulla natura del problema. Ma in generale hai ragione - ci sono diversi tipi di realizzazioni di oggetti (in particolare, userò altri termini per elencarlo). Ad esempio "referencing", "creation", "using", "coordinating", "storing", "inheriting" (!) ....

In base a ciò, l'istanza utente fa riferimento all'istanza dell'account. E un'istanza usa l'istanza B.

Per la maggior parte dei casi è sufficiente distinguere solo "referenziamento" e "utilizzo". È quello che hai appena scritto. È abbastanza comune e astratto essere compreso da un'altra persona quando si parla di dominio, ad es.

Ma a volte, per enfatizzare alcuni aspetti, dovresti descrivere le relazioni in un modo come "Un gruppo di dispacci di Bs" o "R memorizza X nel database". È più applicabile per le specifiche e la modellazione.

Is this a formalised way of recognising different implementations of associations or have I completely lost my mind?

Per chiamare qualcosa di formale, ti suggerisco di dare un'occhiata a UML.

UML e altri strumenti di modellazione

One thing that bugs me is how would I describe the differences in UML or similar? Or is it just an implementation detail?

Ci sono molti modelli UML (diagrammi). Diamo un'occhiata al più noto - Classes and Objects Diagram.

È interessante che UML permetta di presentare tutti i tipi di relazioni tra oggetti, e inoltre permette di decidere "è solo un dettaglio di implementazione".

Martin Fowler descrive 3 livelli (o punti di vista) della comprensione del diagramma delle classi.

  1. concettuale. Il diagramma è considerato un modello di dominio di alto livello, indipendente dall'implementazione.
  2. Specification. Il diagramma è considerato come modello di realizzazione di alto livello contenente interfacce.
  3. Attuazione. Il diagramma è considerato un documento tecnico di basso livello contenente interfacce, classi, riferimenti, altri tipi di relazioni.

Is this a formalised way of recognising different implementations of associations or have I completely lost my mind?

Sì, devi correggere un punto di vista e scegliere il set di relazioni appropriato.

Ad esempio, diamo un'occhiata al diagramma delle classi e consideriamolo dal punto di vista dell'implementazione. UML definisce 3 tipi di relazioni (e propone mezzi corrispondenti alla sua designazione):

Associazione

L'associazione corrisponde al "riferimento" tra le istanze.

Dipendenza

La dipendenza combina tutti i tipi di relazioni come "usare", "creare", "archiviare", ecc.

Inheritance.

Le ereditarietà come strumento OOP fondamentale sono presentate da UML in modo distinto. È più sulle classi che sulle istanze, ma si può anche dire che un'istanza eredita gli attributi dell'istanza B. Quindi, va bene.

Primo e secondo punto di vista su Class Diagram, come ricordo utilizza un solo tipo di relazione che unifica sia le associazioni che le dipendenze ed è designato come associazione (nessuna eredità, ovviamente).

Inoltre, UML propone Objects Diagram che è lo stesso del Diagramma delle Classi, ma si adatta meglio alle esigenze di modellazione runtime.

Infine, la scelta di una serie di relazioni prese in considerazione dipende da un contesto e da un punto di vista. UML ne fornisce alcuni.

    
risposta data 04.09.2014 - 21:51
fonte

Leggi altre domande sui tag