6

So che in linea di principio è possibile trasformare anche linguaggi procedurali come C o MATLAB in oggetti orientati agli oggetti. Questa domanda è stata discussa abbastanza bene here e here.I principi orientati agli oggetti dovrebbero essere applicati nei linguaggi procedurali?

Quello che ho trovato mancante da queste discussioni e le referenze in esso contenute era un'esposizione sul fatto che uno dovrebbe applicare tali principi. C'è qualcosa di concreto da ottenere dal farlo? È chiaramente possibile, ma è consigliabile farlo? Ci sono esempi tra progetti open-source in cui questa pratica ha portato chiari vantaggi?

CHIARIMENTO

Forse un esempio è in ordine.

Ho ereditato del codice MATLAB che implementa un algoritmo di apprendimento automatico. C'è praticamente una singola funzione building_model che, a seconda di una bandierina essere passato, sarà o addestrare un modello o usarlo per prevedere un valore futuro:

building_model('train', ...) % ... stands for the data with which the model is trained 

e

Il modello stesso è implementato con Variabili persistenti MATLAB all'interno di building_model.

Ho lacerato lo building_model in due funzioni, una per l'allenamento e una per la previsione. Il modello che ha usato essere implementato come variabili persistenti è ora esternalizzata, per così dire:

model = new_model() 
model = model_train(model, ...) 
prediction = model_predict(model) 

Questo è, grosso modo, per quanto ho potuto gestire emulare alcune caratteristiche della programmazione orientata agli oggetti in MATLAB. Il modulo del mio modello di edificio ora funziona come una classe, con un costruttore e due metodi model_train e model_predict. Ho raggiunto un certo grado di incapsulamento (sebbene nulla impedisca al chiamante di manipolare gli interni di model) e in linea di principio il polimorfismo potrebbe anche essere accolto. Come bonus extra, ottengo la separazione Command/Query quasi gratis dal model_predict non restituisce model, e quindi non può alterare model.

(i lettori più attenti faranno notare che MATLAB ha già un sistema orientato agli oggetti. Per vari motivi, tra cui prestazioni e la compatibilità con le versioni precedenti, non posso usarlo.)

ho potuto immaginare un meccanismo simile a C dove dovresti progettare una struttura dati e scrivere funzioni il cui primo argomento sarebbe un'istanza di quella struttura dati.

Quello che mi piacerebbe sapere è, fino a che punto posso spingere questo modo di programmazione? È un modello comunemente accettato (lì, ho detto la parola)? Ci sono problemi di prestazioni che dovrei fare attenzione?

+1

Questo è qualcosa che spesso manca dalle discussioni sulle pratiche orientate agli oggetti in generale. Devi ancora decidere se OOP è il progetto giusto, se è incorporato nella lingua o semplicemente una metodologia di progettazione che cerchi di adottare senza l'aiuto della lingua. Gli stessi vantaggi (e svantaggi) si applicano in entrambi i modi. –

risposta

2

Penso che questa sia una discussione molto importante. Penso che sia sicuro dire che OOP non è sempre la soluzione migliore in tutte le lingue. Ad es. C++ o Python, OOP è di solito il modo naturale per es. incapsulare i dati. Quelle lingue sono progettate per concentrarsi sulle classi. In altre lingue, potrebbe essere più facile creare codice di buona qualità in altri modi.

Penso che Common Lisp sia un buon esempio. Ha un ottimo sistema OOP (CLOS) che direi davvero completo. Tuttavia, OOP non viene usato tanto in Common Lisp quanto in Python o C++, poiché è una funzione di comodità piuttosto che qualcosa che è necessario per fornire elementi base di ingegneria del software.

Se si deve utilizzare OOP o non dipende realmente dal problema che si sta tentando di risolvere. Ad esempio, penso che le cose GUI possano essere davvero utili da affrontare con OOP.

+0

+1 "Penso che gli elementi della GUI possano essere davvero utili da affrontare con OOP.". È così che il Dr. Stroustrup introduce OOP ai suoi studenti. – AraK

-1

L'orientamento dell'oggetto è il un mezzo per raggiungere gli obiettivi di ingegneria del software.

Obiettivo: facilità di manutenzione, estensibilità, codice sorgente organizzato (ricerca, ecc.)
OO Construct: Encapsulation (solo i metodi di proprietà del 'tipo di dati/struttura' in grado di operare sui propri dati)

Obiettivo: capacità di sviluppare nuove funzionalità senza modificare quelli esistenti, il riutilizzo del codice
OO Construct : implementazione ereditarietà, polimorfismo

obiettivo: Astrazioni (non c'è bisogno di impegnarsi per un particolare tipo o operazioni, cambio di implementazione senza modificare i clienti)
OO Construct: Interfaccia eredità, interfacce, classi astratte

Gli obiettivi non hanno bisogno di giustificazione. Sia che tu voglia/abbia bisogno del supporto di un linguaggio OO o meno dipende dalla tua particolare situazione. Se hai bisogno di usare C puoi ancora imitare alcuni costrutti OO, e si spera che ne godano i benefici.

Attenzione, è assolutamente possibile sviluppare un grande pasticcio di codice con l'adesione a tutti i principi OO.

Sono sicuro che gli altri possono elencare altri obiettivi ed esempi (e sapere come modificare le tabelle nei post StackOverflow)

+3

Non sono affatto d'accordo sul fatto che OO sia * il * mezzo per raggiungere gli obiettivi di cui sopra. Tutto ciò era davvero possibile prima dell'invenzione di OO. –

Problemi correlati