OO o procedurale

Question

Ho un database di Access che utilizzo per il mio libretto degli assegni (con una buona quantità di VBA abbastanza semplice alle spalle) e mi piacerebbe riscriverlo come programma autonomo con un backend SQL.Sto pensando di utilizzare C++, Java o Python.

Prima di iniziare avevo pensato che l'avrei scritto OO perché pensavo che avrei pensato "in termini OO" (a causa di un corso di logica OO e di un corso di C++ che ho seguito), ma sto scoprendo che posso solo visualizzarlo come procedurale (ma forse perché sono mentalmente bloccato nel pensare a come funziona il db in Access).Come decido?Ho capito bene o sembra che non comprenda i concetti?

Grazie per l'aiuto.

Answer 1

Bene, OO potrebbe essere eccessivo, ma è pratica eccellente. Qualsiasi codice scimmia può scrivere codice procedurale. Il suo percorso di minor resistenza in ogni caso, che è il motivo per cui la maggior parte delle persone lo utilizzano per le applicazioni una tantum che non fanno molto. Tuttavia, se si sta scrivendo per avere esperienza di lavoro con OO, di quello che è meglio pensare in questo modo. Si potrebbe iniziare con la progettazione di un oggetto che gestisce transazioni finanziarie, allora si avrà anche bisogno di un modo di interagire con il DB. Forse si potrebbe scrivere un livello DB dove si astrarre il database chiama dall'oggetto transazione utilizzando Entity Framework dove si poteva imparare LINQ (o qualunque sia il JAVA equivalente è). Questo è tutto partendo dal presupposto che si sta facendo questo per il divertimento e la pratica.

Answer 2

Io suggerirei OO - non è più difficile di quanto la programmazione procedurale, in realtà più facile da mantenere con lo strumento giusto. Delphi sarebbe la mia scelta - grande sostegno di programmazione DB, visual designer, fortemente tipizzato , un sacco di componenti disponibili. Ci sono molti grandi applicazioni scritte in Delphi . Spesso sottovalutato, ci sono molte ragioni che ha un seguito fedele.

Ora ti anatra come la Delphi-haters sono caricate di pomodori.

Answer 3

oo sembra essere eccessivo per una semplice applicazione libretto degli assegni. Provare qualcosa su scala più ampia come qualcosa per gestire tutti i conti finanziari. In questo modo la progettazione di una classe di conto avrebbe senso

Answer 4

Beh, dipende dalla vostra motivazione. Se si desidera un'applicazione libretto degli assegni il più rapidamente possibile, basta sfornare codice di rito. Nessuno tranne voi sapranno la differenza. Se si desidera utilizzare questa applicazione per migliorare se stessi come aprogrammer. Prendetevi il tempo per imparare a scrivere in in OO.

Answer 5

Io andrei con Python:nessuna compilazione e utilizza la digitazione dinamica (puoi anche usare la digitazione rigorosa se lo desideri).Inoltre, ha un enorme seguito nella comunità open source, il che significa ottimo supporto, strumenti e documentazione gratuiti.

Per quanto riguarda OO vs.Procedurale -- tutti questi linguaggi che hai menzionato potrebbero essere scritti in uno stile procedurale -- cioè, una grande classe/metodo che fa tutto -- ma presto scoprirai che vorrai seguire i principi DRY (Non t Ripeti te stesso) e inizia con alcuni metodi privati ​​che fanno bene una cosa particolare.Da allora, vorrai raggruppare cose simili in classi separate, e poi da lì vorrai astrarre quelle classi...vedi dove sto andando qui?

Answer 6

A mio parere si dovrebbe concentrare meno sul OO contro cosa procedurale. Se avete la possibilità di andare procedurale in principio, poi andare procedurale. E 'la cosa più semplice che si può fare per iniziare. La cosa OO, d'altra parte, può altrettanto bene qualificarsi come YAGNI (you are not gonna need it).

Che cosa si dovrebbe fare, però, è quello di scrivere test , unit test e poi i test di integrazione. E si dovrebbe cercare di scrivere test prima. In questo modo, anche se si inizia con un'applicazione procedurale si può in seguito il refactoring in una vera e propria applicazione OO. Ma, solo se avete bisogno di oggetti. Questi test saranno sei rete di sicurezza durante gli spostamenti codice dell'applicazione.

Cercando di pensare le applicazioni in oggetto fin dall'inizio può portare a un punto in cui sei bloccato con le gerarchie di classi e l'architettura.

Non sono un genio, così che io possa essere sbagliato, ma nella mia esperienza, a partire da funzioni semplici e poi pensare a loro raggruppamento in oggetti o moduli è meglio che iniziare col dire: OK , avrò questo oggetto che interagisce con questo oggetto, che sta attuando modello X, così in questo modo sarò disaccoppiare interfaccia Y dall'implementazione Z. in seguito, è possibile osservare che il vostro modello di dominio è debole. Prendete un percorso progettuale evolutivo e iniziare con piccoli blocchi di costruzione.

Answer 7

Se siete alla ricerca di un'applicazione rapida che è possibile estendere, controllare Dynamic Data .