OOP cosa si intende per comunicazione oggetto-oggetto

Non esiste una regola semplice e veloce su quali metodi deve avere un oggetto.

Qualcosa è un oggetto se puoi parlarne come un'entità con un nome familiare agli esperti di dominio nel tuo dominio problematico o nel dominio della soluzione. In sostanza, se si dispone di un set correlato di proprietà e comportamenti a cui è possibile fare riferimento con un solo nome, l'insieme di proprietà e comportamenti è un oggetto.

I comportamenti a cui mi riferisco rientrano in due grandi categorie:

• Richieste di agire. Il classico esempio di Dog::bark() rientra in questa categoria.
• Richieste di informazioni. La maggior parte delle funzioni getter rientrano in questa categoria.

Non c'è niente di sbagliato in un oggetto che ha getter prevalentemente (o solo). Alcuni oggetti in alcuni domini sono solo modelli di un'entità che deve esistere ma che non ha alcun comportamento attivo. La tua classe User potrebbe essere una di quelle.

Una classe X con getter per lo più diventa un odore di codice quando

• ogni getter ha anche un setter per cambiare la proprietà, e
• o la classe X ha invarianti (combinazioni non valide di valori di proprietà) che possono essere infranti se si utilizzano i setter 'erroneamente', o
• la classe Y sta eseguendo operazioni sulle proprietà di X che sarebbero logicamente rientrate nella responsabilità di X.

Un esempio della prima classe con un odore di codice sarebbe una classe come questa:

class Square {
    int x1, x2, y1, y2;
public:
    void SetTopLeft(int x, int y);
    void SetBottomRight(int x, int y);
};

Se si consente di modificare le coordinate in alto a sinistra e in basso a destra in modo indipendente, è molto semplice rompere l'invariante che tutti i lati di un quadrato devono avere la stessa lunghezza e tutti gli angoli sono quadrati.

Un esempio della seconda forma dell'odore del codice è una classe Dog in cui il client sposta un oggetto Tail per far scodinzolare il cane.

what could be the User object Behavior ?

I cannt find any !

login, its an auth lib. thing so i should not include it in user. posting articles is a Post object thing; again user conduct it; but its more of a post object concern to create a post right ? User may be the main Aggregate object in a blog; yet the user is more like the Creator of Other Objects but he does not have a Behavior i can think of; he is being used -and his state- by other objects in most cases that all !

Pensa al sistema che stai modellando e preoccupati di meno di dove avvengono le cose del computer.

Pensa a come lo faresti nel mondo reale. Un post sul blog esiste come una cosa. Ma da dove è venuto? Nella maggior parte dei casi è stato scritto da un autore. Questo è il comportamento . Pertanto, nella modellazione di un sistema con progettazione OO, è opportuno modellare tale comportamento rappresentando un oggetto autore che pubblica post di blog.

"Utente" è un termine troppo generico per avere un significato a questo livello. Pensa agli utenti del sistema in termini di comportamento che eseguono. Un autore dei post del blog è un comportamento molto diverso da un lettore dei post del blog, proprio come un giornalista di un giornale è molto diverso da un lettore di giornali. Questi possono, e probabilmente dovrebbero, essere oggetti diversi.

Se tutti i diversi tipi di utenti condividono un comportamento comune, come l'accesso al sistema, è possibile che vengano ereditati tutti da un oggetto "Utente" principale con un metodo, "autenticarsi".

Questo è un comportamento dell'utente, dopotutto nient'altro accede al sistema se non agli utenti. Possono accedere tramite un sistema di autenticazione, ma tale sistema non effettua il login in sé. Quindi un utente può eseguire il messaggio "autenticarsi" inviando un altro messaggio al sistema di autenticazione dicendo "Qui sono il mio nome utente e la password, per favore autentificami sul sistema".

Non ci sono limiti ai metodi consentiti in un oggetto, ma ci sono filosofie sul comportamento quando si tratta di un buon design. Ci sono molte euristiche (regole empiriche che non offrono garanzie di un buon design, ma che hanno mostrato pregi in passato).

Come affermato da Bart , i comportamenti degli oggetti software possono essere classificati come accessors ( che non cambiano lo stato di un oggetto, ma di solito accedono alle informazioni all'interno dell'oggetto, ad esempio getter) e mutatori (che fanno in qualche modo cambiano lo stato di un oggetto, ad esempio, setter). Normalmente, i due devono essere separati - un accessor non dovrebbe anche modificare lo stato dell'oggetto. La combinazione di questi comportamenti porta a problemi di qualità del software, dal momento che è più difficile testare il funzionamento di questi comportamenti.

Forse se consideri i comportamenti degli oggetti in termini di responsabilità, potrebbe essere d'aiuto. Il design guidato dalla responsabilità è il nome del paradigma, se vuoi trovare maggiori informazioni.

Gli oggetti software non sono oggetti del mondo reale , quindi penso che i numerosi esempi con comportamenti di cani, uccelli, ecc. portino alla confusione. Gli oggetti software fanno parte di un progetto per risolvere un problema legato al mondo reale . Usare gli oggetti dovrebbe aiutare a capire la soluzione di un problema del mondo reale, dal momento che un'astrazione di un oggetto è più vicina al modo in cui pensiamo agli elementi nel dominio del problema reale. Detto questo, i comportamenti software non sono necessariamente comportamenti del mondo reale.

Cani : se stai progettando un software che aiuti i veterinari a gestire la loro attività, potresti avere oggetti Dog. Ma la loro "corteccia" probabilmente non avrà importanza per questo tipo di problema e certamente non sarà un comportamento dell'oggetto software. Tuttavia, potrebbe essere se stai cercando di simulare qualcosa in cui l'abbaiare di un cane fa parte del problema (ad esempio, un gioco di simulazione in cui la polizia compare se troppi cani del giocatore abbaiano nel suo cortile perché sono affamati o annoiato)

Blog : se un blog ha un limite al numero di messaggi che può contenere, un possibile comportamento potrebbe essere quello di "truncate ()" (anche se è discutibile che un blog debba applicare questo comportamento stesso o un'entità esterna). Truncate è un esempio di mutator . Un comportamento a "getAuthor ()" di un blog sarebbe un esempio di un accessore .

I comportamenti non dovrebbero rivelare l'implementazione delle tue classi, se desideri lottare per nascondere le informazioni nel tuo progetto. Per quanto riguarda le altre "regole pratiche" sui comportamenti, ce ne sono molti quando si utilizza il design basato sulla responsabilità (e vedrete che le cose si complicano molto con le aree grigie). Controlla GRASP e SOLID per iniziare (alcune delle regole si sovrappongono - è perché il design del software OO è ancora una disciplina relativamente immatura, rispetto al design Bridge o al design dei mobili).