Mescolando OOP e Non-OOP

Question

Mescolando OOP e Non-OOP

#1 da (4 voti)

1

Sto lavorando a un gioco basato sul testo dell'interfaccia a riga di comando. Lo sto scrivendo in C ma ci sono vari modi in cui posso rifattorizzare il codice usando Objective-C:

utilizzando NSDictionary per permettermi di memorizzare i dati in Plists (più facile da leggere / scrivere a causa del framework Foundation ma di dimensioni molto maggiori) invece del testo semplice
avere classi con metodi (non una cosa grossa ma aumenta la leggibilità del codice)
eliminando la necessità di convertire tra il nome char* di un oggetto e il suo int /% equivalente aenum (usando e enum per rappresentare le cose riduce l'utilizzo e la complessità della memoria quando si usa un OO C semplice, altrimenti dovrei usare strncmp ovunque)

Quello che voglio sapere è se esistono o meno degli svantaggi nel mixare OO- e non-OOP. È ancora a riga di comando, il che significa che la maggior parte verrà scritta in puro non OO C.

Ci sono motivi per cui io non dovrei mescolare questi?

object-oriented c objective-c

posta Arc676 14.09.2015 - 14:25

fonte

1 risposta

Leggi altre domande sui tag object-oriented c objective-c

Lettura dalla memoria vs Esecuzione di un'operazione [chiusa] È agile un buon adattamento quando si presenta contro altri venditori? [duplicare]

score 4 · Accepted Answer

L'orientamento dell'oggetto non è principalmente una funzione linguistica. È un paradigma / metodo / stile di programmazione. Cioè, puoi scrivere perfettamente codice orientato agli oggetti in puro C, e puoi anche scrivere codice perfettamente non orientato agli oggetti in Java.
L'orientamento degli oggetti non è una virtù in sé. È utile la maggior parte del tempo, e quindi giustamente incoraggiato pesantemente, ma ci sono casi d'uso in cui una soluzione non orientata agli oggetti funziona altrettanto bene o meglio.
Non c'è alcun problema con la combinazione di codice orientato agli oggetti e non orientato agli oggetti nello stesso progetto. Il codice orientato agli oggetti può chiamare codice non orientato agli oggetti e viceversa.

L'unico problema che può sorgere è la combinazione di codice scritto in lingue diverse. Ma, come giustamente osserva Doc Brown nei commenti, Objective-C è un superset di C rigido, il che significa che puoi compilare qualsiasi codice C come Objective-C. Questo è molto diverso dal tentativo di compilare il codice C come codice C ++, che imporrà cambiamenti in molti posti. Ma non è un tuo problema, puoi facilmente passare da un suffisso .c a un suffisso .m ovunque ti serva senza rompere il codice nel file.

Detto questo, il tuo obiettivo principale durante il refactoring del tuo gioco dovrebbe essere quello di semplificare il tuo codice. Se conosci bene l'orientamento degli oggetti, semplificare il codice probabilmente significa renderlo strongmente orientato agli oggetti. Se non sai ancora come utilizzare correttamente l'orientamento degli oggetti, prova a trovare almeno due diverse soluzioni orientate agli oggetti per ogni problema e prova a scegliere il migliore in ciascun caso. Ma non cercare di mantenere separato il codice orientato agli oggetti e non orientato agli oggetti.

Riguardo al tuo problema di enum / char* : ti suggerisco di leggere su internare stringa e provare per implementarlo nel tuo gioco. Perché, una volta che hai internato le stringhe, puoi semplicemente confrontare le tue stringhe confrontando il loro puntatore. Ciò dovrebbe consentire di ridurre l'utilizzo di enum in modo flessibile e performante.