è OOP il modello di programmazione dominante nel mondo reale?

In the VIEWPOINT section of Communications of The ACM

Se ti interessa la programmazione pratica , gli atti di ACM e simili sono l'ultima fonte che vuoi leggere. Queste sono spesso pubblicazioni [pseudo] -scientifiche senza alcuna applicazione nel mondo reale. Queste sono opinioni spesso non ortodosse fatte per la pubblicità, perché lo scrittore si distingua dalla folla e promuova la sua stessa persona.

I claim that the use of OOP is not as prevalent as most people believe, that it is not as successful as its proponents claim, and, therefore, that its central place in the CS curriculum is not justified.

Tendo a non essere d'accordo con il tuo punto. OOP è ampiamente diffuso e funziona bene. Con il numero di progetti basati su OOP è probabile che abbia superato gli sviluppi fatti con altre strategie (parliamo del tempo moderno, 15-20 anni).

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

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

P.S. Perché preoccuparsi di ciò che è dominante e cosa no? Prendi solo ciò che è adatto al progetto e lascia i numeri ai "ricercatori".

Se OOP è il paradigma solo che conosci, forse dovresti imparare di più. Ma in realtà, cosa significa in realtà OOP? Significa Java o C ++? Significa Smalltalk? Significa fessure e chiusure di valore impostabile? (Ciao, Schema!) Significa l'invio di messaggi? (Ciao, Erlang!)

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

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

Molte applicazioni stanno facendo semplicemente una programmazione imperativa in cui tutta la logica è impilata in una singola classe o vista. Questa è probabilmente la maggior parte delle semplici applicazioni interne che eseguono tutte le aziende.

Non c'è niente 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.

Se OOP è o meno il modello di programmazione dominante è irrilevante, è sufficiente inserire modelli diversi adatti a casi diversi.

Non c'è un proiettile d'argento.

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

Ma, in realtà, il punto della mia risposta è questo, a che serve affermare che un modello o un altro è dominante o no, è allora una buona ragione per usarla ciecamente? Certo che non lo è.

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

Anche se avessi detto che usiamo OO dove lavoro, significa la definizione tradizionale dell'articolo collegato: Oggetti, Classi, Ereditarietà? O vuol dire che io uso principalmente gli oggetti come mezzo per organizzare il codice? O significa che in realtà sto solo programmando interfacce e non utilizzo affatto l'ereditarietà? Non sto ancora dicendo, ma quale di questi conta davvero come OO?

Non è nemmeno significativo chiedersi se OO è utile fino a quando le domande sopra sono state risolte, per non dire dominanti.

Certo che lo è, perché è l'ultima parola alla quale la gestione si è aggrappata. Offre anche una migliore incapsulamento e astrazione rispetto alla programmazione imperativa, quindi penso che il salto da oop a ciò che viene dopo potrebbe richiedere anche più tempo del necessario per oop.

PS2: If I should choose/learn/use just one approach, is it OOP or not? why?

Se vuoi impararne solo uno devi scegliere un campo diverso.

Dovresti conoscere i tipi e l'incapsulamento e tutti gli altri vantaggi di OOP, e poi imparare come realizzare le stesse cose usando uno stile funzionale di programmazione.

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

Lo affrontiamo, anche le persone che progettano l'hardware digitale, gli stessi progettisti di chip, stanno facendo una transizione verso il duo di SystemVerilog e SystemC. Questi sono linguaggi di programmazione orientati agli oggetti.

Dove non si potrebbe usare OOP? Bene, se si stanno codificando i driver di periferica è difficile immaginare perché si abbia bisogno di una programmazione generica o di un'ereditarietà multipla, oppure se si stanno facendo le tecniche di programmazione funzionale AI lo rendono molto più semplice in testa. Ci sono anche molte altre situazioni, basti dire che l'OOP è un posto piuttosto potente in un mondo di programmazione oligopolistico.

Direi di no.

Capisco che là fuori ci sia un'enorme quantità di codice che viene scritta usando un linguaggio "object-oriented", ma in generale trovo che il codice sia solo procedurale racchiuso nelle classi. (non che questa sia necessariamente una cosa negativa). Il codice che ho visto che è scritto per essere più OO in questi linguaggi tende ad essere un orribile pasticcio di dipendenze tra classi che tipicamente non è gestibile.

OO dovrebbe riguardare il passaggio di messaggi tra oggetti completamente autonomi, e lo vediamo nel codice di oggi, ma a un livello molto più granuloso - cioè vediamo questi oggetti implementati come DLL o assiemi o oggetti COM. 'Componenti' li ho sentiti descritti come.

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

Penso che sia importante ottenere una soluzione diversa applicando un approccio orientato agli oggetti e una soluzione implementata utilizzando il paradigma Object Oriented. La mia opinione su un buon oggetto di software oriente è combinare entrambe le soluzioni. Se pensi negli 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 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 di Object.

Preferisco davvero che il mio codice sia Object Oriented, e ho capito che inizialmente sarebbe stato un po 'più annoying creare una buona struttura, ma quando si tratta di flessibilità e requisiti flash client di oggi, penso ne vale la pena.

Non pretendo di conoscere i numeri esatti, o anche di fare una supposizione approssimativa, ma ci sono molti progetti di programmazione che non coinvolgono OOP. Lavoro con robot industriali. I programmi tendono ad essere codice procedurale abbastanza semplice e diretto. Il vero sistema operativo del robot è ancora di più.

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