Gli algoritmi descrivono cosa dovrebbe fare il computer. La struttura descrive come è strutturato l'algoritmo [nel codice sorgente]. OOP è uno stile di programmazione che sfrutta determinate strutture "orientate agli oggetti".
I libri degli algoritmi spesso evitano OOP perché sono focalizzati sull'algoritmo, non sulla struttura. Frammenti di codice che dipendono fortemente dalla struttura tendono ad essere scarsi esempi da inserire in un libro di algoritmi. Allo stesso modo, i libri di OOP spesso evitano gli algoritmi perché ingombrano la storia. Il punto di forza di OOP è la sua fluidità e il suo aggancio a un algoritmo lo rende più rigido. Si tratta più del focus del libro che di ogni altra cosa.
Nel codice della vita reale, userete entrambi fianco a fianco. Non puoi risolvere i problemi del computer senza algoritmi, per definizione, e troverai difficile scrivere buoni algoritmi senza struttura (OOP o altro).
Come esempio di dove si confondono, prendi la Programmazione dinamica. In un libro di algoritmi, descriveresti come prendere un set di dati omogeneo in un array e usare la Programmazione dinamica per arrivare a una soluzione. In un libro OOP, potresti imbatterti in una struttura come Visitatore, che è un modo per eseguire algoritmi arbitrari su una serie di oggetti eterogenei. L'esempio del libro DP potrebbe essere considerato come un visitatore molto semplice che opera su oggetti in un ordine generalmente dal basso verso l'alto. Il modello Visitatore potrebbe essere considerato lo scheletro di un problema DP, ma manca la carne e le patate. In realtà, scoprirai che spesso hai bisogno di entrambi insieme: usi il modello di Visitatore per gestire l'eterogeneità nel tuo set di dati (DP non va bene in questo) e usi DP all'interno della struttura di Visitatore per organizzare l'algoritmo per ridurre al minimo il runtime (Visitatore doesn'
Vediamo anche algoritmi che operano al di sopra dei modelli di progettazione. È più difficile esprimere esempi in un piccolo spazio, ma una volta che hai una struttura, inizi a voler manipolare quella struttura e usi gli algoritmi per farlo.
Ci sono alcuni problemi che possono essere presentati e risolti solo da OOP?
Questa è una domanda più difficile a cui rispondere di quanto pensi. Per il primo ordine, non esiste alcun motivo computazionale per cui è necessario OOP per risolvere qualsiasi problema. La semplice prova è che ogni programma OOP viene compilato fino all'assemblaggio, che è un linguaggio decisamente non-OOP.
Tuttavia, nel più grande schema delle cose, la risposta inizia a timida verso sì. Raramente sono limitati semplicemente dalle metodologie di calcolo. Il più delle volte ci sono cose come le esigenze aziendali e le capacità degli sviluppatori che incidono sull'equazione. Molte applicazioni oggi non potrebbero essere scritte senza OOP, non perché OOP è in qualche modo fondamentale per il compito, ma perché la struttura fornita da OOP era essenziale per mantenere il progetto sulla buona strada e sul budget.
Ciò non significa che non abbandoneremo mai OOP in futuro per qualche nuova struttura divertente. Dice semplicemente che è uno degli strumenti più efficaci nella nostra cassetta degli attrezzi per una frazione sorprendentemente ampia di attività di programmazione oggi disponibili. I problemi futuri potrebbero portarci ad affrontare lo sviluppo usando strutture diverse. Per uno, mi aspetto che le reti neurali richiedano un approccio di sviluppo molto diverso, che può o meno rivelarsi "orientato agli oggetti".
Non vedo OOP scomparire nel prossimo futuro a causa del modo in cui i progettisti di algoritmi pensano. Ad oggi, il solito schema è che qualcuno progetta un algoritmo che non sfrutta OOP. La comunità OOP si rende conto che l'algoritmo non si adatta davvero alla struttura OOP, e davvero non è necessario, quindi avvolgono l'intero algoritmo in una struttura OOP e iniziano a usarlo. Prendere in considerazione boost::shared_ptr. Gli algoritmi di conteggio dei riferimenti che si shared_ptrtrovano all'interno non sono molto compatibili con OOP. Tuttavia, il modello non è diventato popolare fino a quando non è stato shared_ptrcreato un wrapper OOP attorno ad esso che ha esposto le capacità degli algoritmi in un formato strutturato OOP. Ora, è così popolare che è diventato l'ultima specifica per C ++, C ++ 11.
Perché questo ha tanto successo? Gli algoritmi sono ottimi per risolvere i problemi, ma spesso richiedono un investimento iniziale sostanziale nella ricerca per capire come usarli. Lo sviluppo orientato agli oggetti è molto efficace nel confezionare tali algoritmi e fornire un'interfaccia che richiede un investimento iniziale inferiore per l'apprendimento.