Che tipo di programmi / soluzioni possono essere scritti solo con OOP o sono troppo difficili da ottenere senza di esso? [chiuso]

Tecnicamente, non ci sono problemi nel campo dell'informatica che non possono essere risolti senza OOP. I principi orientati agli oggetti generalmente definiscono il layout e l'architettura del codice sorgente; una volta che il codice è stato compilato in linguaggio assembly per il consumo da parte della CPU, la maggior parte dei pattern di OOP scompare.

Tuttavia, dal momento che molti linguaggi moderni sono progettati per essere orientati agli oggetti, un programma scritto in un linguaggio che non fa uso del supporto integrato per OOP potrebbe effettivamente richiedere più sforzo rispetto alla semplice creazione del programma utilizzando gli strumenti disponibili. Ambienti di memoria gestita come Java / Dalvik VM e .NET CLR usano tipicamente linguaggi progettati da zero per essere O-O, e non c'è modo di evitarlo; per lo meno, è necessario l'oggetto che contiene il metodo main () (e qualsiasi subroutine che chiama).

Per quanto riguarda i programmi che richiedono architettura orientata agli oggetti, penso che quelli che si avvicinano di più sono i programmi di GUI basati sugli eventi. I framework forniti dagli SDK della GUI sono orientati agli oggetti e, mentre sono sicuro che è possibile scrivere un programma CLR composto interamente da hook nel codice dell'API di Windows non gestito per creare e visualizzare finestre e reagire all'input dell'utente in quelle finestre, l'overarching La domanda che pongo di fronte a qualsiasi tentativo del genere è "WHY !?", quando il framework presenta gli oggetti che rappresentano tutti i controlli della GUI, ognuno dei quali gestisce le basi e la maggior parte degli scenari di utilizzo avanzati in un pacchetto ordinato e ordinato?

Questo è la forza della programmazione orientata agli oggetti; il "concetto di scatola nera". Non devi preoccuparti di come qualcosa è effettivamente fatto; ti interessa semplicemente che sia fatto quando lo vuoi. Perché collegare una dozzina di funzioni API di Windows e fare centinaia di chiamate per visualizzare una finestra sullo schermo, quando puoi semplicemente chiamare Form.Show ()?

Per quanto riguarda la gestione convincente che l'OOP sia una buona cosa, l'argomento riguarda tutto il tempo. OOP è stato progettato per salvare il tempo dello sviluppatore aumentando il riutilizzo del codice. Gli oggetti codice generici, che esistono già in modo da non doverli riscrivere , sono derivati e combinati nella soluzione specifica per il tuo particolare problema di programmazione. Questi oggetti sono anche modulari (se segui i modelli di progettazione Gang of Four che incoraggiano l'adesione a principi di progettazione come GRASP o SOLID), ovvero se un software ha un problema (non deve essere un bug, i programmi vengono aggiornati in base a sempre su nuovi requisiti, e il motivo di un aggiornamento software è un "problema", altrimenti non si aggiorna il software), la / e riga / i di codice responsabile del comportamento corrente e che deve cambiare per mostrare il i nuovi comportamenti sono facili da trovare, facili da modificare e, se necessario, più facili da sostituire rispetto alle linee del "codice spaghetti" procedurale.

Nello sviluppo del software, il tempo è denaro; ci sono pochi o eventuali costi dei materiali diretti per una soluzione software (principalmente costi di avviamento), quindi il driver principale del costo di un pezzo di software è il numero di ore di sviluppo necessarie per crearlo. Seguendo l'OOP, ti garantisco che saranno necessarie meno ore di sviluppo per qualsiasi programma non banale che ignorarlo.

What kind of programs cannot be written unless you use OOP?

A causa della completezza di Turing non ce ne sono.

What kind of programs are not recommended to be written using non-OOP techniques? What kind of programs need OOP in order to even be written? What kind of programs would be too hard to write without OOP ?

OOP è un bene quando si hanno oggetti "naturali": pulsanti della GUI, file, prese, serrature, ecc. In quasi tutti i linguaggi non OO si vedono questi oggetti con oggetti opachi chiamati handle.

OOP è una mancata corrispondenza quando il progetto si rivolge ai processi di trasformazione dei dati e alle azioni. Rimani bloccato nel Regno di nomi di Yegge. Fondamentalmente, ogni volta che si ha un verbo, o un verbo-er si è deviato oltre i limiti del buon gusto in terra OO.

Ecco perché i linguaggi multi-paradigma sono la strada da percorrere. OO non è lo strumento migliore per ogni lavoro e nessun altro approccio. Non solo, ma ci sono relativamente poche applicazioni che sono ad approccio singolo appropriato. Quindi, quello che facciamo attualmente è guardare quale sia l'approccio migliore per il 70% della tua app, quindi corri il resto del 30% in qualcosa di orribile contro il mostro della palude di cattivo design.

OO è un modo per organizzare i programmi. Per rendere il caso per OO, hai bisogno di un programma abbastanza grande che la sua organizzazione sia importante (sì i principianti sono ora addestrati in un modo di pensare OO senza alcuna esperienza di programmi abbastanza grandi per essere importanti, ma quelli che incontro spesso sono come te, incapace di spiegare perché è buono, e quindi incapace di vedere quando non lo è).

Ovviamente non dipende solo dalla dimensione del programma (con quale metrica BTW), ma anche molto di ciò che fa il programma. Il caso più semplice di OO è probabilmente quello dei simulatori, lì il modo di pensare OO mappa in modo così pulito il dominio del problema che è difficile discutere. Di fatto, è stato uno dei casi d'uso dietro OO (Simula è uno dei primi linguaggi OO e ha portato il supporto linguistico a tecniche già utilizzate ma non formalizzate, e il C ++ è iniziato con l'intenzione di ridurre il sovraccarico di Simula).

Ora, avrai un momento molto difficile per vendere OO a un project leader abbastanza esperto da vedere che quello su cui stai lavorando è un caso in cui OO porta solo i costi generali senza compensare i benefici.