Qual è il vantaggio della programmazione orientata agli oggetti rispetto alla programmazione procedurale?

Sto cercando di capire la differenza tra linguaggi procedurali come C e linguaggi orientati agli oggetti come C ++. Non ho mai usato C ++, ma ho discusso con i miei amici su come differenziare i due.

Mi è stato detto che C ++ ha concetti orientati agli oggetti e modalità pubbliche e private per la definizione delle variabili: cose che C non ha. Non ho mai dovuto usarli per lo sviluppo di programmi in Visual Basic.NET: quali sono i vantaggi di questi?

Mi è stato anche detto che se una variabile è pubblica, è possibile accedervi ovunque, ma non è chiaro come sia diverso da una variabile globale in una lingua come C. Non è inoltre chiaro come una variabile privata differisca da una variabile locale.

Un'altra cosa che ho sentito è che, per motivi di sicurezza, se è necessario accedere a una funzione, questa deve essere ereditata per prima. Il caso d'uso è che un amministratore dovrebbe avere solo tutti i diritti di cui ha bisogno e non tutto, ma sembra che funzionerebbe anche un condizionale:

if ( login == "admin") {
    // invoke the function
}

Perché questo non è l'ideale?

Dato che sembra esserci un modo procedurale per fare tutto orientato agli oggetti, perché dovrei preoccuparmi della programmazione orientata agli oggetti?

Tutte le risposte finora si sono concentrate sull'argomento della tua domanda come indicato, che è "qual è la differenza tra c e c ++". In realtà, sembra che tu sappia qual è la differenza, semplicemente non capisci perché avresti bisogno di quella differenza. Quindi, altre risposte hanno tentato di spiegare OO e incapsulamento.

Volevo entrare in contatto con l'ennesima risposta, perché in base ai dettagli della tua domanda, credo che tu debba fare diversi passi indietro.

Non capisci lo scopo di C ++ o OO, perché a te sembra che la tua applicazione debba semplicemente archiviare i dati. Questi dati sono memorizzati in variabili. "Perché dovrei voler rendere inaccessibile una variabile? Ora non posso più accedervi! Rendendo tutto pubblico, o meglio ancora globale, posso leggere i dati da qualsiasi luogo e non ci sono problemi." - E hai ragione, in base alla scala dei progetti che stai scrivendo, probabilmente non ci sono molti problemi (o ci sono, ma non ne sei ancora consapevole).

Penso che la domanda fondamentale a cui devi veramente rispondere sia: "Perché dovrei mai voler nascondere i dati? Se lo faccio, non posso lavorarci!" Ed è per questo che:

Diciamo che inizi un nuovo progetto, apri il tuo editor di testo e inizi a scrivere funzioni. Ogni volta che devi memorizzare qualcosa (per ricordarlo per dopo), crei una variabile. Per semplificare le cose, rendi le tue variabili globali. La tua prima versione della tua app funziona alla grande. Ora inizi ad aggiungere altre funzionalità. Hai più funzioni, alcuni dati che hai archiviato prima devono essere letti dal tuo nuovo codice. Altre variabili devono essere modificate. Continui a scrivere più funzioni. Quello che potresti aver notato (o, in caso contrario, lo noterai assolutamente in futuro) è che, man mano che il tuo codice diventa più grande, ci vuole sempre più tempo per aggiungere la funzione successiva. E man mano che il codice diventa più grande, diventa sempre più difficile aggiungere funzionalità senza interrompere qualcosa che funzionava. Perché? Perché devi ricordare cosa tuttole variabili globali sono la memorizzazione ed è necessario ricordare dove tutto di loro vengono modificati. E devi ricordare quale funzione va bene chiamare in quale ordine esatto e se le chiami in un ordine diverso , potresti ricevere errori perché le tue variabili globali non sono ancora del tutto valide. Ti sei mai imbattuto in questo?

Quanto sono grandi i tuoi progetti tipici (righe di codice)? Ora immagini un progetto da 5000 a 50000 volte più grande del tuo. Inoltre, ci sono più persone che ci lavorano. Come possono tutti i membri del team ricordare (o anche essere consapevoli di) cosa stanno facendo tutte quelle variabili?

Quello che ho descritto sopra è un esempio di codice perfettamente accoppiato. E fin dagli albori del tempo (supponendo che il tempo sia iniziato il 1 ° gennaio 1970), il genere umano ha cercato modi per evitare questi problemi. Il modo per evitarli è suddividere il codice in sistemi, sottosistemi e componenti e limitare il numero di funzioni che hanno accesso a qualsiasi dato. Se ho 5 numeri interi e una stringa che rappresentano un qualche tipo di stato, sarebbe più facile per me lavorare con questo stato se solo 5 funzioni impostassero / ottengano i valori? o se 100 funzioni impostano / ottengono questi stessi valori? Anche senza i linguaggi OO (cioè C), le persone hanno lavorato duramente per isolare i dati da altri dati e creare confini di separazione netti tra le diverse parti del codice. Quando il progetto raggiunge una certa dimensione, la facilità di programmazione non diventa "posso accedere alla variabile X dalla funzione Y",

Questo è il motivo per cui sono stati introdotti concetti OO ed è per questo che sono così potenti. Ti permettono di nascondere i tuoi dati da te stesso e vuoi farlo apposta, perché meno codice vede quei dati, meno possibilità ci sono che quando aggiungi la prossima funzione, rompi qualcosa. Questo è lo scopo principale dei concetti di incapsulamento e programmazione OO. Ti consentono di suddividere i nostri sistemi / sottosistemi in caselle ancora più granulari, al punto in cui, indipendentemente da quanto sia grande il progetto complessivo, un determinato set di variabili è accessibile solo da 50-200 righe di codice e basta! Ovviamente c'è molto di più nella programmazione OO, ma, in sostanza, questo è il motivo per cui C ++ ti offre la possibilità di dichiarare dati / funzioni come privati, protetti o pubblici.

La seconda idea più grande in OO è il concetto di strati di astrazione. Sebbene i linguaggi procedurali possano anche avere astrazioni, in C, un programmatore deve fare uno sforzo consapevole per creare tali livelli, ma in C ++, quando dichiari una classe, crei automaticamente un livello di astrazione (dipende ancora da te se questa astrazione è o meno aggiungerà o rimuoverà il valore). Dovresti leggere / ricercare di più sui livelli di astrazione e se hai più domande, sono sicuro che questo forum sarà più che felice di rispondere anche a questi.

Hmm ... forse è meglio eseguire il backup e provare a dare un'idea dell'intento di base della programmazione orientata agli oggetti. Gran parte dell'intento della programmazione orientata agli oggetti è consentire la creazione di tipi di dati astratti. Per un esempio davvero semplice con cui hai sicuramente familiarità, considera una stringa. Una stringa in genere avrà un buffer per contenere il contenuto della stringa, alcune funzioni che possono operare sulla stringa (cercare in essa, accedere a parti di essa, creare sottostringhe, ecc.) Avrà anche (almeno in genere) qualcosa da tenere traccia della lunghezza (corrente) della stringa e (probabilmente) della dimensione del buffer, quindi se (per esempio) si aumenta la dimensione della stringa da 1 a 1000000, saprà quando è necessaria più memoria per contenere il più grande soddisfare.

Quelle variabili (il tampone, lunghezza attuale e la dimensione del buffer) sono private per la stringa stessa, ma sono non locale per una particolare funzione. Ogni stringa ha contenuti di una determinata lunghezza, quindi dobbiamo tenere traccia di quel contenuto / lunghezza per quella stringa. Al contrario, la stessa funzione (ad esempio, per estrarre una sottostringa) potrebbe operare su molte stringhe diverse in momenti diversi, in modo che i dati non possano essere locali per la singola funzione.

Come tale, finiamo con alcuni dati che sono privati ​​della stringa, quindi è solo (direttamente) accessibile alle funzioni di stringa. Il mondo esterno può ottenere la lunghezza della stringa usando una funzione stringa, ma non è necessario conoscere nulla degli interni della stringa per ottenerla. Allo stesso modo, potrebbe modificare la stringa, ma di nuovo lo fa tramite le funzioni di stringa e solo loro modificano direttamente quelle variabili locali all'oggetto stringa.

Per quanto riguarda la sicurezza, noterei che sebbene ciò sia ragionevole come un'analogia, non è come le cose funzionano davvero. In particolare, l'accesso in C ++ è specificamente non destinato a soddisfare lo stesso tipo di requisiti di accesso in un sistema operativo. Si suppone che un sistema operativo imponga le restrizioni in modo che (ad esempio) un utente normale non possa fare cose riservate a un amministratore. Al contrario, il controllo degli accessi in C ++ ha solo lo scopo di prevenire incidenti. In base alla progettazione, chiunque lo desideri può aggirarli abbastanza facilmente. Sono nello stesso ordine in cui si contrassegna un file di sola lettura in modo da non eliminarlo accidentalmente. Se decidi di eliminare il file, è banale cambiarlo da sola lettura a lettura-scrittura; impostarlo su sola lettura è farti almeno pensarci un secondo e decidere di eliminare il file in modo che non venga eliminato per sbaglio solo dal colpire la chiave sbagliata al momento sbagliato.

OOP contro C non riguarda davvero nessuna delle cose che hai discusso. Si tratta principalmente di impacchettare il codice in aree che non si interessano / non possono involontariamente (o talvolta anche intenzionalmente) a vicenda.

C consente sostanzialmente di eseguire qualsiasi funzione da qualsiasi luogo. OOP lo impedisce raggruppando i metodi in classi e consentendo solo di utilizzare i metodi facendo riferimento alla classe che li contiene. Quindi, un vantaggio potenzialmente grande di OOP è che è molto più probabile che tu abbia una migliore disposizione del codice senza molta esperienza per dirti che dovresti.

Una classe ben scritta dovrebbe essere una piccola "isola di fiducia": puoi usarla e presumere che faccia "la cosa giusta" e che ti protegga dalle insidie ​​più comuni. Ciò rende una buona classe un elemento costitutivo, che è molto più riutilizzabile come un insieme di funzioni e variabili, che potrebbe funzionare bene ma mostrandoti tutte le loro brutte viscere e costringendoti a capire come lavorano insieme, come devono essere inizializzati ecc. Una buona classe dovrebbe essere come una presa USB, mentre la soluzione procedurale è come un mucchio di fili, chip, stagno e un pezzo di saldatura.

Un punto che non è stato discusso in profondità è l'aspetto dell'interfaccia / implementazione. Un'interfaccia descrive il comportamento, ma non la realizzazione. Quindi un'interfaccia di elenco descrive il concettodi un elenco e il suo comportamento: ti aspetteresti cose come aggiungere, rimuovere e ridimensionare i metodi. Ora ci sono molti modi diversi per implementare questo elenco, ad esempio come un elenco collegato o usando un buffer di array. Il potere della programmazione OO è che utilizzando un'interfaccia è possibile ragionare sul comportamento senza conoscere l'implementazione. L'accesso alle variabili o ai metodi interni eliminerebbe questa astrazione, non è possibile sostituire un'implementazione dell'elenco con un'altra e non è possibile migliorare un'implementazione esistente senza toccare il codice utilizzando la classe. Questo è uno dei motivi principali per cui sono necessarie variabili e metodi privati: per proteggere i dettagli interni dell'implementazione, in modo che l'astrazione rimanga intatta.

OO va anche oltre: ad esempio per le biblioteche puoi definire un'interfaccia per cose che non esistono ancora e scrivere codice che funziona con quell'interfaccia. Gli utenti possono scrivere classi che implementano l'interfaccia e utilizzare i servizi forniti dalla libreria. Ciò consente un grado di flessibilità che non è possibile con la programmazione procedurale.

C'è un modo per fare tutto con una macchina Turing, o almeno in un linguaggio assembly per il codice macchina che un programma C o C ++ finirà per compilare.

Quindi la differenza non riguarda cosa può fare il codice, ma cosa può fare la gente.

Le persone fanno errori. Molte.

OOP introduce un paradigma e una sintassi che aiuta a ridurre le dimensioni e la densità di probabilità dello spazio di possibili errori di codifica umana. A volte, rendendo illegale l'errore per una determinata classe di oggetti dati (come non è un metodo dichiarato per quell'oggetto). A volte rendendo l'errore più dettagliato, o stilisticamente strano, rispetto all'uso canonico della lingua. A volte richiedendo un'interfaccia con utilizzi incoerenti o impigliati molto meno possibili (pubblici vs. privati). eccetera.

Più grande è il progetto, maggiore è la probabilità di errori. A cui un nuovo programmatore potrebbe non essere esposto se sperimentato solo con piccoli programmi. Quindi la potenziale perplessità sul perché OOP è preziosa.

La tua domanda sembra più sullo scopo di OOP piuttosto che sulla differenza. Il concetto nel tuo post è Incapsulamento; e l'incapsulamento esiste per supportare CHANGE. Quando altre classi accedono ai tuoi interni diventa difficile modificarli senza romperli. In OOP fornisci un'interfaccia (membri pubblici) attraverso la quale permetti ad altre classi di interagire con le tue e nascondi i tuoi interni in modo che possano essere tranquillamente cambiati.

Non importa dove leggo le variabili private non sono accessibili, mentre le variabili pubbliche possono essere perché non rendere pubblico come globale e privato come locale qual è la differenza? qual è il vero uso del pubblico e del privato? per favore non dire che può essere usato da tutti, suppongo perché non usiamo alcune condizioni e facciamo le chiamate?

Spero che tu non voglia mai più di una stringa nella tua applicazione. Spero anche che le variabili locali persistano tra le chiamate di funzione. Queste cose potrebbero essere le stesse in termini di accessibilità ma in termini di durata e altri usi? Non sono assolutamente gli stessi.

Come molti hanno detto, qualsiasi programma, una volta compilato, viene trasformato in un codice binario e, poiché una stringa binaria potrebbe essere utilizzata per rappresentare un numero intero, qualsiasi programma alla fine è solo un numero. Tuttavia, definire il numero necessario potrebbe essere piuttosto difficile ed è per questo che sono emersi linguaggi di programmazione di alto livello. I linguaggi di programmazione sono solo modelli del codice assembly che alla fine producono. Vorrei spiegarti la differenza tra la programmazione procedurale e la programmazione OO mediante questo bellissimo documento sulla programmazione orientata al contesto http://www.jot.fm/issues/issue_2008_03/article4/

come puoi vedere da questa immagine, illustrata nel documento, la programmazione procedurale fornisce solo una dimensione per associare un'unità computazionale a un nome. Qui, le chiamate oi nomi delle procedure sono direttamente associati alle implementazioni delle procedure. Nella figura-una chiamata m1 non lascia altra scelta se non l'invocazione della sola implementazione della procedura m1.

La programmazione orientata agli oggetti aggiunge un'altra dimensione per la risoluzione dei nomi a quella della programmazione procedurale. Oltre al nome del metodo o della procedura, l'invio del messaggio prende in considerazione il destinatario del messaggio quando cerca un metodo. Nella Figura b vediamo due implementazioni del metodo m1. La selezione del metodo appropriato non dipende solo dal nome del messaggio m1, ma anche dal destinatario del messaggio effettivo, qui Ry.

Questo in effetti consente l'incapsulamento e la modularizzazione.

La figura c riguarda infine la programmazione orientata al soggetto che estende l'invio di metodi orientati agli oggetti di un'altra dimensione.

Spero che questo ti abbia aiutato a pensare a OOP da una prospettiva diversa.

(+1) Fare una domanda su qualcosa che non capisci, va bene, anche se sembra sciocco.

La differenza è la programmazione orientata agli oggetti e alle classi. "Plain C", funziona con dati e funzioni. "C ++" aggiunge concetti "oggetto e classi", oltre a numerosi concetti secondari correlati.

Tuttavia, consiglio agli sviluppatori di imparare "Plain C" prima di "C ++". O "Procedal Pascal" prima di "Object Pascal".

Molti sviluppatori pensano che gli studenti dovrebbero insegnare solo una cosa.

Ad esempio, vecchi insegnanti che non ottengono OO e insegnano solo "Plain Structured C".

O insegnanti "hipster" che insegnano solo OO, ma non "Plain C", perché "non ne hai bisogno". O entrambi, senza preoccuparsi dell'ordine di insegnamento.

Penso piuttosto che agli studenti dovrebbero essere insegnate sia la "C strutturata normale" che la "C orientata agli oggetti (C ++)". Con "Plain C", prima e "C ++", successivamente.

Nel mondo reale, devi imparare entrambi i paradigmi (oltre ad altri paradigmi, come "funzionale").

Pensare ai programmi strutturati come a un "oggetto" grande e singleton può essere d'aiuto.

Dovresti anche porre l'accento sugli spazi dei nomi ("moduli"), in entrambe le lingue, molti insegnanti lo ignorano, ma è importante.

In una parola, gestione del progetto. Ciò che intendo è che C ++ mi aiuta a far rispettare le regole su come il mio codice viene utilizzato da altri. Lavorando su un progetto di 5,5 milioni di linee trovo molto utile la programmazione orientata agli oggetti. Un altro vantaggio è il compilatore che fa sì che io (e tutti gli altri) seguiamo determinate regole e rileviamo errori minori in fase di compilazione. Tutti i vantaggi teorici ci sono anche, ma volevo solo concentrarmi sulle cose pratiche quotidiane. Dopo tutto, tutto viene compilato in codice macchina.

La programmazione orientata agli oggetti è la programmazione procedurale, con caselle.

In PP, hai una casella, uno stato, che diventa incredibilmente grande man mano che il progetto cresce, causando la comparsa di effetti collaterali ogni volta che dimentichi un po 'di quel grande stato.

In OO, hai molte scatole, molti stati e man mano che il progetto cresce, le scatole crescono un po 'e il numero di scatole cresce molto.

Resta più facile guardare scatole più piccole, è facile avere l'illusione di un intero quadro, ma in realtà quasi impossibile, dato che guardare classi e interfacce nasconde i dettagli di implementazione che possono avere ramificazioni importanti.

Nella programmazione funzionale, hai molte caselle funzionali e decidi che ogni funzione ha una voce (parametri) e un'uscita (ritorni), senza assolutamente nessun altro accesso al contesto esterno.

Poiché non esiste uno stato e nessun effetto collaterale (in base alla progettazione), è possibile analizzare in modo sicuro qualsiasi funzione separatamente dall'insieme e sapere al 100% come si comporterà in qualsiasi circostanza.

Dato che stai inscatolando codice per unità logiche che rappresentano azioni, diventa anche possibile avere solo una casella per azione tipica.

Ciò ridurrà il codice di qualsiasi progetto su larga scala di un fattore enorme rispetto a OOP che promuove nascondere più funzioni analogiche in tutta la base di codice in diverse classi.

Questo batterà anche PP di gran lunga perché puoi far crescere il progetto molto più a lungo poiché non c'è più stato XXXXXXXL da tenere traccia.

In sintesi, PP è probabilmente il modo più semplice per avvicinarsi a un programma semplice e FP è probabilmente il modo più semplice per avvicinarsi a un programma complesso.

Se si tiene conto dell'obiettivo di unificare tutte le basi di codice e migliorare il riutilizzo del codice, FP dovrebbe sempre essere utilizzato, poiché è l'unico paradigma che ha senso su larga scala, nonché l'unico paradigma che ha una riusabilità del 100% (è possibile semplicemente copia incolla una funzione e usala da qualche altra parte, senza alcun sovraccarico).

E ottieni test di unità affidabili al 100% gratuitamente.

E non devi scrivere "final statico privato of_doom genius awesome string_1".

E ottieni parallelismo gratis.

La semplice differenza di una frase è che C ++ è C con Classi (anche se ora è molto di più) Non so perché non vuoi imparare le differenze tra due leggendo un ottimo articolo su C ++ su Wikipedia .... Questo articolo ti aiuterà moltissimo: - C ++ (Wikipedia)

Anche googling sulla questione aiuterà. Chiedere a persone a caso di spiegarlo potrebbe essere complicato. IMHO, si capisce meglio leggendo che chiedendo a qualcuno