Best practice per raggruppare le costanti correlate

3

Sto lavorando al codice degli elementi finiti in MATLAB , e il numero di costanti (ad esempio, l'input dell'utente che definisce la geometria, la fisica, lo schema di soluzioni numeriche) è sostanziale. Attualmente, ho passato le variabili tra le subroutine usando le istruzioni global , ma queste non offrono alcuna indicazione su quali siano le variabili o quale sia il loro utilizzo; non ideale come il codice si espande.

Voglio incapsulare le costanti correlate in oggetti MATLAB (ad esempio GEOMETRY , per tutte le costanti di geometria, ecc. In questo caso d'uso, saranno essenzialmente delle strutture, non avranno funzioni private associate.) È questa cattiva pratica di codifica? Sembra funzionare in modo contrario a tutto ciò che conosco sulla buona programmazione orientata agli oggetti.

Alla fine (una volta che ho finito la prototipazione), voglio convertire tutto in C ++, quindi la mia preoccupazione principale è fare ciò in modo accettabile in entrambi i paradigmi di programmazione.

Note:

  • MATLAB consente la definizione di "oggetti" in un modo molto ad hoc:

    GEOMETRY.DX = DX;
    GEOMETRY.DY = DY;
    

mentre il C ++ richiederebbe la definizione di una classe; Mi piacerebbe ridurre al minimo l'editing interlinguale richiesto.

  • Gli array non sono una soluzione adeguata. I dati sono correlati allo scopo, ma non sono tutti della stessa dimensione, tipo, ecc. L'uso degli oggetti assicura 1, come i dati sono raggruppati; 2, ogni volta che si fa riferimento ai dati, si fa riferimento usando il suo nome originale; 3, la confusione del codice, le contraddizioni e l'ambiguità dalle istruzioni global vengono rimosse.

Sto "violando le regole" usando gli oggetti come ho proposto? Se è così, c'è un modo migliore per strutturare i miei dati? Grazie.

    
posta Dominic Jarecki 28.03.2018 - 20:22
fonte

1 risposta

-1

I'm working on Finite Element code in MATLAB, and the number of constants (for instance user input defining the geometry, physics, numerical solution scheme) is substantial.

Probabilmente hai appena chiamato i tre oggetti in cui queste costanti dovrebbero risiedere.

Currently, I've been passing variables between subroutines using global statements,

Sì, smettila di farlo.

but these offer no indication what the variables are or what their use is; not ideal as the code expands.

Non è l'ideale con minuscoli bit di codice.

I want to encapsulate related constants in MATLAB objects (for instance GEOMETRY, for all the geometry constants, etc. In this usage case, they will essentially be structs; they will have no associated private functions

Ed ecco il tuo problema. Perchè no? Questo non è orientato agli oggetti. Se non metti qui i metodi che hanno bisogno delle costanti, stai girando l'oggetto verso l'esterno. Diffondere la conoscenza rende il codice ridicolo. Nascondi ciò che gli altri tuoi oggetti non hanno bisogno di sapere da loro. Non costringermi a chiedere Geometry per le cose di cui ho bisogno. Consentitemi di dire a Geometry cosa fare. Vedi, racconta, non chiedere 1 , 2 .

I want to encapsulate related constants in MATLAB objects (for instance GEOMETRY, for all the geometry constants, etc. In this usage case, they will essentially be structs; they will have no associated private functions.) Is this bad coding practice? It seems to run contrary to everything I know about good object-oriented programming.

L'incapsulamento fatto bene è più del clustering. Posso vedere le tue costanti da fuori. Ciò significa che ne sono a conoscenza. Ciò significa che finirò a dipendere da loro. Ciò significa che non puoi cambiarli, rinominarli o spostarli senza infranmi. Usa i dati nascosti e puoi fare quello che vuoi con loro e non lo saprò mai.

Eventually (once I'm done prototyping), I want to convert everything to C++, so my main concern is doing this in a way that is acceptable in both programming paradigms.

Una lingua non è un paradigma. Il tuo paradigma è, apparentemente, orientato agli oggetti. Puoi farlo in lingue nemmeno progettate per questo. Devi solo seguire le sue pratiche.

Se saltare da una lingua all'altra trasforma la conversione nella tua preoccupazione principale, magari usi solo una lingua. La tua preoccupazione principale dovrebbe essere il problema che stai cercando di risolvere. Tutto ciò che ti distrae è meglio che tu stia facendo qualcosa di straordinario per te.

whereas C++ would require definition of a class

Le classi non sono obbligate a scrivere codice orientato agli oggetti.

Am I "breaking the rules" using objects as I've proposed? If so, is there a better way to structure my data?

Stai rompendo una cosa molto importante. Diffondere la conoscenza intorno a ferisce la flessibilità. Preferirei vederti definire pi in più posti, quindi fallo. Se la costante è qualcosa che vuoi regolare in un posto, allora rendi quel luogo un cittadino pieno di diritti e metodi di gruppo attorno ad esso.

Ma se insisti a fornire l'accesso a cose che non ne hanno bisogno, almeno fai in modo che i luoghi che hai messo alle costanti pubbliche siano facili da trovare. Trovo che PI in Math stia bene. Ma questa è una biblioteca. Le persone che gestiscono il tuo software avranno molte altre cose a cui pensare. Non chiedere a loro di memorizzare una struttura complicata per trovare le costanti che stanno cercando. Evita nomi come Misc . Rendi la struttura e i nomi significativi.

    
risposta data 28.03.2018 - 21:39
fonte

Leggi altre domande sui tag