Quando le classi vogliono unire

Question

Ho un problema con 2 classi che una volta erano ben separate, ma ora vogliono accoppiarsi.

Senza entrare troppo nello specifico del problema, qui è:

Ho usato per avere un triangolo di classe che conteneva 3 vertici spazio posizioni.

C'erano molte istanze Triangolo nel programma, quindi ciascuna aveva mantenuto la propria copia dei loro vertici. Funzioni membro come getArea(), getCentroid() ecc. Sono state scritte nella classe Triangle e poiché ciascuna istanza di Triangle ha copie dei vertici a, bec, la ricerca dell'area o del centroide non ha avuto alcuna dipendenza da altre classi. Come dovrebbe essere!

Quindi volevo passare a una rappresentazione in stile vertex-array/index buffer, per altri motivi. Ciò significa che tutti i vertici sono memorizzati in un singolo array situato in un oggetto Scene e che ogni Triangle conserva solo REFERENCES sui vertici in Scene, non copie dei vertici stessi. In un primo momento, ho provato il passaggio per i puntatori:.

class Scene 
{ 
    std::vector<Vertex> masterVertexList ; 
} ; 

class Triangle 
{ 
    Vertex *a,*b,*c ; // vertices a, b and c are pointers 
    // into the Scene object's master vertex list 
} ; 

(Nel caso vi stiate chiedendo circa i benefici, l'ho fatto per motivi per lo più a che fare con i triangoli che condividono i vertici Se * poi un muove tutti i triangoli che usa quel vertice sono aggiornati automaticamente).

Questa sarebbe stata una soluzione davvero buona! Ma non ha funzionato in modo affidabile, because std::vector invalidates pointers, e stavo usando un vettore std :: per l'elenco dei vertici principali nella classe Scene.

Così ho dovuto usare interi:

class Triangle 
{ 
    int a,b,c ; // integer index values 
    // into the Scene object's master vertex list 
} ; 

Ma ora ho questo nuovo problema di accoppiamento: per trovare la propria area o baricentro, classe di accesso Triangle bisogno di class Scene dove prima non ha fatto. Sembra che abbia fatto qualcosa di fsck, ma non proprio.

WWYD?

Answer 1

Mi sembra che il tuo Triangolo dipenda realmente dalla tua Scena (poiché i suoi vertici sono tutti membri di quella particolare scena), quindi non c'è da vergognarsi nel fare l'oggetto. In effetti, probabilmente darei al Triangolo un membro obbligatorio di Scene *.

Answer 2

Supponendo di disporre di un solo Scene, è possibile trasformarlo in un oggetto singleton e accedere all'elenco dei vertici tramite metodi statici.

Se si dispone di più oggetti Scene, ogni Triangle appartiene esattamente a uno Scene - e deve "sapere" a quale scena appartiene. Pertanto, è necessario inizializzare ogni triangolo con un riferimento Scene e memorizzarlo come membro della classe.

Answer 3

Perché non solo lo vector in Scene memorizza solo i puntatori?

std::vector<Vertex *> masterVertexList; 

In questo modo, Triangle possono continuare a utilizzare Vertex * 's e tutto quello che dovete fare è assicurarsi che i puntatori sono cancellati in Scene' distruttore s.

Answer 4

Il passaggio da non accoppiato a accoppiato è un risultato naturale della decisione di condividere i vertici laddove possibile. Precedentemente, ogni triangolo "possedeva" i suoi vertici e la scena (presumibilmente) possedeva un mazzo o triangoli.

Permettere ai triangoli di condividere i vertici cambia il modello fondamentale - quando/se un vertice può essere condiviso tra due o più triangoli, nessun triangolo può più possedere quel vertice. Anche se è possibile (ad esempio, con qualcosa di simile a shared_ptr) per avere uno schema di proprietà condivisa, quello che stai facendo in questo momento è probabilmente più semplice: ogni vertice ha ancora un singolo proprietario, ma il proprietario è ora la scena invece del triangolo individuale.

Poiché un triangolo è ora solo un modo conveniente di raggruppare alcuni vertici nella collezione "possedere" invece di possedere i vertici stessi, non è una sorpresa che ci sia un accoppiamento più stretto tra il triangolo e la collezione che possiede i suoi vertici. Se ci tieni molto a riguardo, potresti comunque nascondere la proprietà condivisa per mantenere almeno l'aspetto del tuo precedente accoppiamento perdente.

L'idea generale sarebbe abbastanza semplice: invece di ogni triangolo conoscendo la scena che contiene i vertici del triangolo, si creerebbe una classe proxy vertice che combini un ID scena e un indice vertice, in modo che il triangolo possa manipolare il vertice oggetto proxy proprio come in precedenza avrebbe l'oggetto vertice. Non si elimina completamente l'accoppiamento più stretto, ma si isola la "conoscenza" dell'accoppiamento più stretto a una singola classe, ovvero solo responsabile del mantenimento dell'aspetto dell'accoppiamento più lento.

L'ovvia lacuna di questo sarebbe che gli oggetti proxy di vertice sono suscettibili di memorizzare una discreta quantità di dati ridondanti. Ad esempio, tutti i proxy dei vertici in un particolare triangolo rappresentano chiaramente i vertici nella stessa scena. Se memorizzi l'ID scena esplicitamente per ogni proxy del vertice, stai memorizzando tre copie dell'ID scena invece di una che avresti avuto in precedenza. A volte vale la pena - altri no. Se è un problema reale, potresti provare a trovare un modo per evitare di memorizzare l'ID scena in modo esplicito, ma questo probabilmente implicherà alcuni trucchi che non sono (anche vicini) agnostici del linguaggio.

Answer 5

È possibile passare il vettore al triangolo nel suo costruttore in modo che possa mantenere un riferimento al vettore. Quindi non è necessario accedere o conoscere una scena.

typedef std::vector<Vertex> VertexContainer; 

class Scene 
{ 
    VertexContainer masterVertexList ; 
} ; 

class Triangle 
{ 
    // A references to the vertices contained in Scene. 
    // A triangle no longer needs to know anything about a scene 
    VertexContainer& vertexListRef; 

    // index into vertexListRef of the triangles points. 
    VertexContainer::size_type a; 
    VertexContainer::size_type b; 
    VertexContainer::size_type c; 

    public: 
     Triangle(VertexContainer&   masterVertexList, 
       VertexContainer::size_type x, 
       VertexContainer::size_type y, 
       VertexContainer::size_type z) 
      :vertexListRef(masterVertexList) 
      ,a(x),b(y),c(z) 
     {} 
}; 

Answer 6

Se si sta solo aggiungendo o togliendo alle estremità della lista vertice, utilizzare un deque invece.

Answer 7

Non penso sia troppo male. Triangle ha perso un po 'di generalità ed è diventato una classe periferica di Scene, ma se non è usato come interfaccia esterna (e quel tipo di collegamento ai buffer interni non lo suggerisce), questa è solo un'evoluzione naturale.

La mia soluzione sarebbe simile alla tua sotto il cofano, ma con più zucchero.

struct Triangle 
{ 
    Triangle(...) { ... } 
    Vertex *a(),*b(),*c() ; // trivia: this is valid syntax! Getters adjust… 
private: 
    size_t ax, bx, cx; // … offsets… 
    Scene *client; // … into the Scene object's master vertex list. 
} ; 

In questo modo, non c'è bisogno di riorganizzare le cose in memoria, e adattare il vecchio codice richiede semplicemente l'aggiunta di ()-->a e .a, ecc, che può essere fatto da ricerca e sostituzione, e migliora OO stile comunque.

Oppure, eliminare il costruttore e private e renderlo POD.