Devo memorizzare x, y coordinate come una matrice, un oggetto di classe o due variabili?

Question

Devo memorizzare x, y coordinate come una matrice, un oggetto di classe o due variabili?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)
#6 da (0 voti)
#7 da (0 voti)
#8 da (0 voti)

5

Ho un MyObject che ha una coordinata x e y.

Per quanto posso vedere, posso memorizzarlo in tre modi:

class MyObject:
    def __init__(self, x, y):
        self.x = x
        self.y = y

class MyObject:
    def __init__(self, x, y):
        self.position = [x, y]

class MyObject:
    def __init__(self, x, y):
        self.position = Coord(x,y) #Coord class created elsewhere

Esiste una buona pratica in entrambi i casi?

Dove sto pensando che questo sia rilevante, è quando passi queste coordinate in altri metodi:

ad es.

myObj = MyObject(0,0)
searchLocation(myObj.x, myObj.y)
searchLocation2(myObj.position)

variables python

posta dwjohnston 05.09.2014 - 03:50

fonte

8 risposte

Leggi altre domande sui tag variables python

Integrare la funzionalità di ripristino del pacchetto NuGet nella procedura di checkout Progettazione di una configurazione di autorizzazioni totali con prestazioni migliori per più livelli di autorizzazione

score 1 · Answer 1

Se non si dispone di dati sufficienti per decidere, scegliere l'opzione più flessibile. La scelta dell'oggetto ti consentirebbe di avere le altre due opzioni come proprietà. (Anche se, come suggerisce il commento, sceglierei una tupla su una lista.)

score 0 · Answer 2

Penso che la terza implementazione di MyObject sia la migliore poiché separa l'oggetto dalla matematica 2D del sistema di coordinate. (è possibile implementare una libreria matematica completa per le coordinate ed è completamente indipendente dagli oggetti creati). Ora per rendere gli oggetti più flessibili puoi creare funzioni che prendono due numeri per xey o un oggetto Coord e preparati a aggiungerne altri man mano che il tuo sistema cresce.

score 0 · Answer 3

Sì, dipende da quanto sia "di prima classe" la posizione. Se molti altri oggetti lo consumano o lo producono e / o c'è un comportamento che ha a che fare con le posizioni che vuoi catturare / applicare (come da Gus's answer), allora probabilmente starai meglio a farne una sua classe.

Se fai vai a farne una sua classe, dovresti decisamente allontanarti dal prendere gli elementi xey nel costruttore su MyObject e invece farlo prendere un oggetto posizione. Probabilmente non c'è motivo per cui MyObject debba essere a conoscenza di cosa deve essere costruito un oggetto Position, almeno non ovviamente dall'esempio fornito (anche se accetto ci potrebbero essere dei motivi per non farlo in alcune situazioni).

score 0 · Answer 4

Penso che una risposta che ti porti tutto il comportamento che vuoi con un overhead del codice zero sia usare una serie Pandas. Supporta l'accesso per indice, accedendo per nome del campo (es. Xe .y), e supporta anche operazioni element-element fuori dalla scatola, così sarai in grado di aggiungere e sottrarre le tue coordinate senza dover sovraccaricare alcun operatore .

score 0 · Answer 5

Darei un'occhiata alla classe namedtuple * dalla libreria standard. È fondamentalmente un modo automatico di sottoclassi di una tupla con proprties denominati per ogni campo corrispondente.

link

Se hai bisogno di fare operazioni vettoriali e matriciali, potresti invece cercare in NumPy, che è composto da tipi di dati numerici altamente funzionali:

link

score 0 · Answer 6

Quanto spesso userete x senza y o viceversa? Se la tua risposta è raramente o mai, allora raggruppali in una tupla o in una classe. Se usare una tupla o una classe è un'altra domanda. Una regola empirica comune è quella di utilizzare una classe se avrà due o più metodi, e in caso contrario utilizzare una tupla. Un namedtuple ti offre la convenienza di denominazione dei membri della classe pur essendo leggero come le tuple normali.

Questa risposta parla dell'utilizzo di namedtuple con punti, come nell'esempio.

score 0 · Answer 7

Ci sono diverse regole che uso quando lo faccio. Si applicano a tutti i tipi di cose, non solo alle coordinate xey, ma anche ai criteri di ricerca, agli insiemi di flag, ai set di parametri numerici e così via.

Detto questo, non tutti usano questi principi e spesso puoi trovare codice di alta qualità che prende altre decisioni.

Quattro o più parametri dovrebbero di solito essere refactored negli oggetti

Se la tua funzione richiede quattro o più parametri, dovresti provare a rifattorizzarli in oggetti che li raggruppano.

Il motivo è che quattro parametri per una funzione sono in genere semplicemente troppo . In una chiamata di funzione, diventa difficile tenere traccia di quali argomenti si intendono per quali parametri, specialmente se alcuni parametri assumono un valore predefinito o sono facoltativi.

Linee di codice come queste sono piuttosto frustranti da vedere:

SomeMethod(1, null, null, 1, 0)
SomeMethod(1, 1, 1, null, 5)

Nelle lingue che supportano i parametri formali denominati, questo è meno di un problema. Ma di solito le persone non si preoccupano di specificare il nome di un parametro quando non devono farlo.

Inoltre, se dopo il refactoring ti trovi ancora di fronte a una funzione con quattro o più parametri, probabilmente hai problemi più grandi.

Gli insiemi di 2+ parametri che appaiono frequentemente insieme dovrebbero essere refactored negli oggetti

Questo caso tocca il caso delle coordinate, poiché in un progetto che richiede le coordinate, di solito devi definire molte funzioni che le prendono come parametri.

Se questi parametri appaiono così frequentemente nelle chiamate ai metodi, probabilmente c'è un strong legame tra loro.

I set di parametri che controllano la funzionalità estensibile devono essere inseriti in un oggetto

Ad esempio, se hai un metodo come:

Search(string name, int age, DateTime date, ...)

Dove ha senso che l'elenco di parametri sia esteso con l'aggiunta di altri criteri, allora dovresti inserire l'insieme di criteri in un oggetto.

score 0 · Answer 8

Se le prestazioni sono della massima importanza, memorizzale come due variabili. Ciò significa che meno oggetti heap vengono allocati e, quindi, i costi generali della raccolta dati obsoleti sono inferiori.

Ovviamente, l'OP ha chiesto di Python, quindi l'OP probabilmente non si preoccupa molto delle prestazioni, ma qualcuno potrebbe leggerlo e usare per es. Java, nel qual caso le prestazioni potrebbero essere importanti.

Si può usare Array (o per Python, tupla) se si ha un piano per estendere il codice da 2 dimensioni a N dimensioni. Altrimenti, non preoccuparti.