Modo manutentivo per mantenere gli oggetti in memoria

Question

Modo manutentivo per mantenere gli oggetti in memoria

#1 da (1 voti)

2

Sto cercando di capire il modo migliore per mantenere gli oggetti in memoria senza averli sparsi ovunque all'interno del codice.

Ad esempio: ho un sistema di menu PyQT che interagisce con gli oggetti. Attualmente, questi menu sono in grado di creare e modificare un oggetto colpendo il codice al di fuori dei file relativi ai menu, ma in seguito gli oggetti si trovano all'interno degli stessi oggetti del menu.

es.

from foo_obj import Foo

class Menu
foo = Foo()
...

Alcuni oggetti a cui è necessario accedere da più menu siedono nel proprio file dove vengono salvati in una variabile e importati nel file di "livello più alto" ( main.py ) in modo che non vengano distrutti fino alla fine del programma .

Sono sicuro che questo non è il modo migliore per farlo. Ho sentito parlare del design di MVC e ho cercato di seguire qualcosa del genere in cui quasi tutte le logiche del controller, come la modifica di oggetti, condizionali, ecc. Sono nei loro stessi file "controllori" e i file di menu sono quasi interamente viste. Sfortunatamente, il problema rimane ancora che non riesco a trovare un buon modo per archiviare questi oggetti senza creare una sorta di concetto astratto come object_container.py .

Qual è un buon approccio per questo tipo di problema?

design clean-code python import

posta e15purple 09.02.2018 - 23:17

fonte

1 risposta

Leggi altre domande sui tag design clean-code python import

Devo raggruppare campi dati e viste relativi, oppure racchiudere tutti i campi dati (e anche le viste) in una singola classe? Serializzazione automatica netta vs differenza di serializzazione personalizzata

score 1 · Accepted Answer

Some objects that need to be accessed from multiple menus sit in their own file where they are saved to a variable and imported into the "highest-level" file (main.py) so they aren't destroyed till the program terminates.

I'm sure this is not the best way to go about this.

Questo è esattamente ciò che Iniezione di dipendenza ti dice di fare. Mark Seemann ha chiamato dove si esegue questa operazione CompositionRoot . L'unica ragione per cui non l'ha semplicemente chiamato main era perché alcuni framework screwball non ti lasciano il codice principale. Ti fanno codice da qualche parte sotto quello. Sta dicendo anche così, componi i tuoi oggetti più in alto nella pila di chiamate che puoi. Inoltre, non è necessario disporre di una struttura di contenitori di iniezione a dipendenza di fantasia per fare questo lavoro. Pure-DI , come lo chiama ora, è davvero solo un buon vecchio riferimento che passa vestito con un nome di fantasia per vendere libri e software. Ma il modo di costruire e comporre oggetti longevi in alto anche se li si usa in basso è da molto tempo. Funziona ancora bene oggi, nome di fantasia o no.

Questo non significa che non puoi utilizzare schemi creativi come fabbrica astratta. Significa che gli oggetti sono pensati per vivere finché il programma deve iniziare (e terminare) la vita nella tua composizione radice (principale). Dopo aver finito di costruirli, chiami un metodo su quella cosa che hai costruito e avvialo. Questo separa il codice di costruzione dal codice di comportamento.

MVC non ha nulla a che fare con ciò. Si tratta di separare le responsabilità in componenti separati in modo che possano cambiare indipendentemente. MVC è vecchio. Non parla ad altro. Non sa quando creare questi componenti o come lasciarli parlare tra loro. Quando l'abbiamo inventato, non avevamo idea di come gli oggetti dovessero parlarsi. È così vecchio.

Ci sono altri modelli che parlano di questo problema che potrebbe valer la pena studiare. Uno è Domain Driven Design . Parla di una costruzione di una radice aggregata che si prende cura di questo problema. Ha delle regole per isolarlo dagli altri aggregati che risiedono in altri domini.

C'è anche Clean Architecture che ti dice di costruisci un grafo di oggetti che segue il principio di inversione di dipendenza tutto in una volta e lascia che i livelli parlino ai livelli attraverso le astrazioni. Sei libero di costruire tutto questo in un istante e poi avviarlo. Nessun contenitore o aggregato richiesto.

In ognuno di questi casi dovresti essere in grado di costruire le cose che vanno nel tuo menu, quindi costruire il tuo menu e passare quelle cose nel menu.

Esistono altri schemi di contenitori come localizzatore di servizi . Il problema principale è che possono finire forzando un sacco di altri codici per sapere che il localizzatore di servizi esiste. Questo è male semplicemente perché meno un oggetto sa che meno cose possono far male quando cambiano. Crea abbastanza oggetti fragili e presto non sarai in grado di apportare modifiche. Non vorrai toccare il codice perché ogni volta che lo fai si rompe.

Quindi sì, ci sono modi per andare male qui. Ma hai dei modi decenti per andare bene.