OOP è il modello di programmazione dominante nel mondo reale?

Gli oggetti mai? Bene, quasi mai

Nella sezione VIEWPOINT di Communications of The ACM, ho trovato un articolo interessante intitolato " Oggetti mai? Bene, quasi mai ". È una prospettiva radicalmente diversa rispetto agli oggetti prima o agli oggetti in ritardo. Suggerisce "oggetti-mai" o forse "oggetti-scuola di specializzazione".

L'autore ha parlato di OOP e ha posto una domanda su come OOP viene utilizzato negli ambienti di programmazione del mondo reale. Pensa che OOP non sia il modello di programmazione dominante. Ad esempio, afferma, il 70% delle programmazioni viene eseguito per sistemi embedded in cui OOP non è realmente adatto.

Quando alcuni professori nelle università vogliono parlare dei vantaggi di OOP, parlano di riutilizzo del codice. Come altro esempio, afferma ancora, questo non è il caso reale nel mondo reale. il riutilizzo del codice è più difficile di quanto affermato nelle università:

Dichiaro che l'uso di OOP non è così diffuso come la maggior parte delle persone crede, che non ha successo come sostengono i suoi sostenitori e, quindi, che il suo posto centrale nel curriculum CS non è giustificato.

È interessante per me sapere come la gente in stack-overflow pensa a questo? OOP è il modello di programmazione dominante dal punto di vista dei programmatori?

Se dovessi scegliere / imparare / usare solo un approccio, è OOP o no? perché?

Nella sezione VIEWPOINT di Communications of The ACM

Se sei interessato alla programmazione pratica , gli atti di ACM e simili sono l'ultima fonte che vuoi leggere. Queste sono spesso pubblicazioni [pseudo] scientifiche senza applicazione nel mondo reale. Queste sono spesso opinioni poco ortodosse fatte per la pubblicità, per lo scrittore di differenziarsi dalla folla e promuovere la propria persona.

Dichiaro che l'uso di OOP non è così diffuso come la maggior parte delle persone crede, che non ha successo come sostengono i suoi sostenitori e, quindi, che il suo posto centrale nel curriculum CS non è giustificato.

Tendo a non essere d'accordo con il tuo punto. OOP è ampiamente diffuso e funziona bene. In base al numero, i progetti basati su OOP hanno probabilmente superato gli sviluppi realizzati con altre strategie (parliamo dei tempi moderni, 15-20 anni).

Tuttavia OOP non è un proiettile d'argento. Funziona per alcuni sviluppi, non funziona per altri. Proprio come qualsiasi altro approccio.

Ma una cosa che devo menzionare è che un curriculum dovrebbe comunicare la conoscenza di diversi approcci. Se è basato su OOP, è sbagliato. Se è basato su FP, è sbagliato. Dovrebbe coprirli tutti o non toccare del tutto questo argomento.

PS Perché preoccuparsi di ciò che è dominante e di ciò che non lo è? Basta prendere ciò che è adatto per il progetto a portata di mano e lasciare i numeri ai "ricercatori".

Se OOP è l' unico paradigma che conosci, forse dovresti saperne di più. Ma davvero, cosa significa veramente OOP? Significa Java o C ++? Significa Smalltalk? Significa slot di valore impostabili e chiusure? (Ciao, Schema!) Significa invio di messaggi? (Ciao, Erlang!)

In breve, sembra una domanda poco interessante da porre. "OO è utile ?" è una domanda migliore. E, beh, sembra così. (Certamente è per me.)

Dove stanno facendo tutti gli sviluppatori quel "70% delle programmazioni"? di tutti gli sviluppatori che conosco meno dell'1% lavora su sistemi embedded.

Quindi, abbiamo 3 opzioni:

1. Sono unico e tutti i tuoi amici programmano davvero
2. Ci sono eserciti di sviluppatori bloccati in un seminterrato da qualche parte che fanno quel 70%
3. questa statistica è inventata e l'articolo è una cazzata

se non vedo alcune prove che le opzioni 1 o 2 sono effettivamente vere vado con l'opzione 3.

(A proposito, non considero la programmazione integrata dello sviluppo mobile moderno e lo sviluppo mobile è spesso OO, dopo tutto Apple ti costringe a utilizzare * Obiettivo * C per sviluppare per iPhone)

Non ho fatti per seguirlo, ma OOP non è il modello di programmazione dominante. Immagina tutte quelle app sviluppate da qualcuno che ha seguito un corso di base visivo o ha fatto una programmazione macro in Excel.

Molte applicazioni stanno semplicemente eseguendo una programmazione imperativa in cui tutta la logica è raggruppata in una singola classe o vista. Questa è probabilmente la stragrande maggioranza delle semplici applicazioni interne in esecuzione in tutte le aziende.

Non c'è nulla di sbagliato in questo, ci sono diversi modi per risolvere lo stesso problema. Alcuni più adatti di altri.

Inoltre, come hai sottolineato, OOP non è utile per tutti gli scenari. Ci sono anche altri modelli.

Indipendentemente dal fatto che OOP sia il modello di programmazione dominante è irrilevante, basta semplicemente inserire modelli diversi per casi diversi.

Non esiste un proiettile d'argento.

Ciò di cui Moti Ben Ari sta discutendo è un'affermazione accademica, che è già insignificante. Tuttavia, si afferma che non ha mai trovato OOP "sensato", chiaramente lo fa per migliaia di sviluppatori e ingegneri del software ed è stato utilizzato in molti sistemi ...

Ma, davvero, il punto della mia risposta è questo: a che serve affermare che un modello o un altro è dominante o no, è allora una buona logica per usarlo ciecamente? Certo che no.

Questa è in realtà una domanda difficile a cui rispondere in modo affidabile. Il motivo principale sono le persone come me, che lavorano in applicazioni personalizzate e interne, in cui il codice non lascia mai il nostro edificio. Usiamo OO qui? Non sto dicendo. Quanti altri programmatori hanno lavori simili? Nemmeno stanno dicendo. Disponiamo di siti di lavoro, ma non tutti i lavori vengono pubblicati e non tutti i lavori sono rivolti a lavori reali rispetto ai reclutatori che cercano di raccogliere elenchi di nomi.

Anche se ho detto che usiamo OO dove lavoro, ciò significa la definizione tradizionale dall'articolo collegato: Oggetti, Classi, Ereditarietà? O significa che uso principalmente gli oggetti come mezzo per organizzare il codice? O vuol dire che programmo davvero solo interfacce e non uso quasi mai l'ereditarietà? Non sto ancora dicendo, ma quale di questi conta davvero come OO?

Non è nemmeno significativo chiedere se OO è utile fino a quando le domande di cui sopra non avranno avuto una risposta, per non parlare di dominante.

Certo che lo è, perché è l'ultima parola d'ordine a cui il management ha attaccato. Offre anche una migliore incapsulamento e astrazione rispetto alla programmazione imperativa, quindi penso che il salto da oop a qualunque cosa venga dopo potrebbe richiedere anche più tempo di quanto sia necessario l'imperativo.

PS2: se dovessi scegliere / imparare / usare solo un approccio, è OOP o no? perché?

Se ne imparerai solo uno, dovresti scegliere un campo diverso.

Dovresti conoscere i tipi e l'incapsulamento e tutti gli altri vantaggi di OOP e quindi imparare a realizzare quelle stesse cose usando uno stile funzionale di programmazione.

OOP è sicuramente uno dei modelli di programmazione più dominanti nel mondo reale.

Ammettiamolo, anche le persone che progettano hardware digitale, i progettisti di chip stessi, stanno facendo una transizione al duo di SystemVerilog e SystemC. Questi sono linguaggi di programmazione orientati agli oggetti.

Dove non verrebbe utilizzato OOP? Bene, se stai codificando i driver di dispositivo è difficile immaginare perché avresti bisogno di una programmazione generica o di ereditarietà multiple O se stai facendo delle tecniche di programmazione funzionale AI per renderlo molto più semplice sulla testa. Ci sono anche molte altre situazioni, basti dire che OOP è un posto abbastanza potente per essere in un mondo di programmazione oligopolistica.

Direi di no.

Capisco che esiste un'enorme quantità di codice là fuori che viene scritta usando un linguaggio "orientato agli oggetti", ma generalmente trovo che il codice sia semplicemente procedurale racchiuso in classi. (non che questa sia necessariamente una cosa negativa). Il codice che ho visto che è scritto per essere più OO in queste lingue tende ad essere un orribile pasticcio di dipendenze tra le classi che è tipicamente non mantenibile.

Si suppone che OO riguardi il passaggio di messaggi tra oggetti completamente autonomi, e lo vediamo nel codice di oggi, ma a un livello molto più granulare - cioè vediamo questi oggetti implementati come dll o assembly o oggetti COM. "Componenti" li ho sentiti descritti come.

quindi, penso che non importa se OO viene usato o meno - se il codice è mantenibile durante la sua vita, riutilizzabile nella misura in cui è stato progettato per essere, e veloce da sviluppare, quindi non mi interessa se è puramente procedurale o semi-oggetto orientato o completamente OO. Dubito che qualcuno possa dirti se lo stile predominante è uno di questi, ma rischierei di immaginare che lo stile procedurale sarà il più comune, anche se suddiviso in classi anziché funzioni.

Penso che sia importante differenziare una soluzione ottenuta applicando un approccio orientato agli oggetti e una soluzione implementata USANDO il paradigma orientato agli oggetti. La mia opinione su un buon oggetto oriente software è quella di combinare entrambe le soluzioni. Se pensi agli oggetti e rispetti le definizioni e le interazioni degli oggetti e il tuo problema potrebbe essere adattato per usare questa struttura, allora avrai un codice che è flessibile e robusto. Ma se usi gli oggetti per risolvere un codice usando un paradigma procedurale, finirai con un brutto mix che non trarrà vantaggio dai professionisti degli Oggetti.

Preferisco davvero che il mio codice sia orientato agli oggetti, e mi sono reso conto che all'inizio potrebbe essere un po 'più fastidioso creare una buona struttura, ma quando si tratta di flessibilità e requisiti di flash client di oggi, penso che valga la pena sforzo.

Non pretendo di conoscere i numeri esatti, o nemmeno di fare un'ipotesi approssimativa, ma ci sono molti progetti di programmazione che non coinvolgono OOP. Lavoro con robot industriali. I programmi tendono ad essere un codice procedurale abbastanza semplice e diretto. L'attuale sistema operativo del robot lo è ancora di più.

Molti dei nostri "strumenti" che utilizziamo sono basati su OOP, ma funzionano su PC e non sul controller del robot. Questi includono editor, simulazioni e utilità.