Variabili private e vecchi blocchi comuni FORTRAN [chiuso]

Question

Variabili private e vecchi blocchi comuni FORTRAN [chiuso]

#1 da (3 voti)
#2 da (0 voti)

2

Questa è una domanda che mi lascia perplessi sulla programmazione orientata agli oggetti. In alcuni linguaggi OOP (ad esempio C ++) una funzione membro può accedere a variabili private della classe senza restrizioni. Ciò significa che è possibile definire metodi che non accettano argomenti e modificano le variabili private. Non è considerata una cattiva pratica di programmazione? Un sacco di pensiero è andato su come gli argomenti delle funzioni possono essere passati per valore o riferimento e cosa ciò implica sulla complessità del programma.

Vorrei fare questa domanda di meno sull'opinione e più sui fatti. Consideriamo la dichiarazione goto. L'istruzione goto è stata deprecata come cattiva pratica di programmazione a favore della programmazione strutturata. Qualche dato oggettivo è entrato in questa decisione? Sembra intuitivo che goto sia problematico, ma esiste una base fattuale per la deprecazione? Sono stati studiati programmi, sondaggi condotti, ecc.?

Tornando alla mia domanda sulle funzioni dei membri, c'è una base obiettiva per rispondere a questa domanda? Le funzioni membro di una classe dovrebbero poter manipolare variabili non presenti nell'elenco degli argomenti? C'è stata una ricerca per determinare questa domanda? Esiste una branca della ricerca informatica che tenta di determinare le migliori pratiche nella progettazione del linguaggio sulla base di criteri oggettivi?

Grazie.

object-oriented programming-languages c++ object-oriented-design fortran

posta Anthony Mannucci 22.11.2015 - 06:15

fonte

2 risposte

Leggi altre domande sui tag object-oriented programming-languages c++ object-oriented-design fortran

E 'possibile non avere un array con indice zero con javascript? [chiuso] Utilizzo di un'equazione definita dall'utente per calcolare un intero elenco di numeri e memorizzare l'elenco in una matrice

score 3 · Answer 1

Ci sono alcune importanti differenze tra membri privati di una classe e variabili globali.

Le variabili globali sono accessibili da qualsiasi parte del codice, a condizione che l'autore del codice conosca il nome della variabile globale. I membri privati sono accessibili solo alle funzioni membro della stessa classe.
Inoltre, nella maggior parte dei linguaggi OO, le variabili membro sono per impostazione predefinita membri istanza e le funzioni membro possono accedere solo ai membri dell'istanza degli oggetti passati alla funzione (implicitamente chiamando il membro su un oggetto o esplicitamente ).

Ciò significa che la tua proposta fa già parte della maggior parte delle lingue OO, tranne che i membri privati non vengono passati singolarmente, ma piuttosto en-bloc (tramite this o self puntatore / riferimento ).

score 0 · Answer 2

Pur essendo sovraffollato dal settore, la possibilità di salvare la programmazione orientata agli oggetti è stata quella di incoraggiare i programmatori a scrivere codice più facile da seguire per altri programmatori, con meno commenti.
In termini di riutilizzo del codice e semplicità del codice, l'OOP sfortunatamente tende a fornire vantaggi limitati e, perversamente, finisce di solito con il risultato di più linee di codice. Uno dei maggiori vantaggi di OOP è la riduzione dell'uso di elenchi di argomenti lunghi, ridondanti e schizzinosi per le funzioni. Quando hai una funzione con 8 argomenti, 6 di essi sono condivisi con una dozzina di altre funzioni, questo è il momento in cui appare questo vantaggio.
Lo svantaggio di cercare di tracciare lo stato mutabile o le variabili di tipo globale è uno che continua a dog OOP. Per questi motivi, i linguaggi di programmazione funzionale come Haskell, Erlang, F # e Scala hanno continuato a raccogliere stampa e utilizzo negli ultimi anni. Vediamo anche funzioni di programmazione funzionale, come il trattamento di funzioni come cittadini di prima classe, che si stanno facendo strada nelle lingue OOP negli ultimi anni.
In termini di best practice, la maggior parte dei teorici di OOP probabilmente direbbe che le proprietà di classe dovrebbero essere usate con parsimonia, che le funzioni dovrebbero essere ridotte e le proprietà di classe dovrebbero essere scrivibili solo all'interno della classe (a parte essere passati a esemplificazione). Mentre questo risolve gli svantaggi, non applica le migliori pratiche. Il risultato di questa e di altre caratteristiche controverse in OOP (come l'ereditarietà) è che possono esserci molti dibattiti e confusione sul modo migliore di implementare OOP.