Appello del datore di lavoro; Uso OOP nel mainstream; soluzioni che fioriscono con OOP

Penso che il malinteso più comune su OOP sia che dovrebbe rendere molto più facile la scrittura del software. Ecco da dove vengono alcune delle critiche, perché quando si scrive software, OOP spesso significa più e talvolta anche meno codice naturale. Questo è ciò che rende difficile vedere i vantaggi di OOP, poiché chiunque inizia a programmare scrive solo nuovi programmi e non deve mai mantenere quelli esistenti.

Tuttavia, il vero vantaggio di OOP si mostra solo quando è necessario mantenere software nel corso degli anni, mentre si cambiano costantemente parti del programma in modi che nessuno si aspettava quando furono scritti per la prima volta.

Dovresti vedere OOP come un modo per assicurarti che le modifiche locali al software rimangano locali e non influenzino il resto del programma. In questo senso, le classi sono una sorta di segnaposto esplicito per i cambiamenti futuri. In un programma procedurale è spesso difficile vedere dove è necessario modificare il codice per aggiungere una funzionalità completamente nuova, senza influire su nient'altro.

Sicuramente puoi scrivere programmi procedurali che sono anche estensibili, ma devi pensarci e progettarlo correttamente. OOP ti fornisce un'idea generale di come i programmi possono essere strutturati per mantenerli mantenibili, il che significa che non devi pensare tanto al design! Lo stesso vale per altri paradigmi di programmazione, OOP non è necessariamente il più comune in questo momento.

Quindi, in conclusione, penso che l'unico modo per capire veramente OOP sia cambiare e aggiungere funzionalità al software esistente. Questo è il compito più comune per i programmatori comunque, e dovrebbe essere facile! Non avere un buon design rende più difficile di quanto non debba essere.

Questo tipo di difficoltà rende difficile rispondere alla tua domanda, poiché qualsiasi progetto può trarre vantaggio da OOP se è abbastanza complesso e deve essere mantenuto ed espanso. Penso che i progetti che possono avere un numero qualsiasi di funzionalità impreviste, tali giochi o bot, siano dei buoni esempi. Puoi anche lavorare su un programma open source, che è in generale il modo migliore di praticare la programmazione avanzata.

In primo luogo, non tutte le applicazioni dovrebbero essere incorniciate da scarpe nel paradigma OO. La programmazione procedurale è molto viva e una valida alternativa a OO per alcuni casi (javascript e php per esempio). Se si può effettivamente un codice più pulito, più espressivo e più efficace in uno stile procedurale rispetto a quello che un collaboratore potrebbe utilizzare, allora si avrà certamente un valore per un datore di lavoro. Detto questo, qualsiasi datore di lavoro ha appeso parole buzz (il cui denaro spende ancora) o impiega un progettista di applicazioni il cui progetto è previsto implementare, potrebbe essere meno che soddisfatto se sei (incerto? Non convinto? So che ero non convinto per un anno o due) sui concetti di OO. Ti suggerirei di provare un libro su modelli di design (Head First Design Patterns è fantastico) per portare la tua comprensione OO al livello successivo. Spero che questo aiuti.

Non esiste un programma elegante in C, a meno che non contenga esempi eccessivamente banali. I vantaggi di OO diventano intrinsecamente evidenti non appena si tenta di fare anche qualcosa di semplice, come le stringhe. Se non riesci a capire perché std::string sia molto meglio delle stringhe C in ogni modo possibile, devi dare un'occhiata più da vicino. Ti darò un vantaggio dimostrando alcuni dei grandi vantaggi:

La classe di stringhe Standard gestisce tutta la sua memoria - in particolare, sei garantito per non perdere mai, mai, una std::string . È molto più avanti di una stringa C.

La classe di stringhe Standard offre dimensioni O (1). Le stringhe C offrono solo la dimensione O (n).

La classe di stringhe Standard non richiede la terminazione NULL. Questo risolve molti errori "off-by-one" che esistono nel codice stringa C.

La classe di stringhe standard non può avere la memoria liberata da un altro utente. Non può avere la memoria essere riallocata da un altro utente. La proprietà è esplicita e imposta dal compilatore. Se passi una char* a una funzione, potrebbero tentare di liberarla quando lo fai già, o cose del genere.

La classe di stringhe Standard è più intelligente di te. Nello specifico, può fare cose come l'ottimizzazione delle stringhe di piccole dimensioni senza dover modificare il codice utente. Se si desidera implementare SSO, è necessario refactoring ogni singolo bit di codice che utilizza le stringhe. Quando std::string implementa SSO, non te ne accorgi nemmeno.

La classe di stringhe standard è generica. La funzione per l'ordinamento di un vettore di numeri interi è la stessa di quella per l'ordinamento di un vettore di stringhe, ed è anche più veloce del qsort di C.

La classe di stringhe Standard cresce quando necessario. Non più codici MAGIC_BUFFER_SIZE che superano il limite e sono vulnerabili e puoi garantire che il tuo implementatore di librerie abbia impiegato molto tempo, molto più tempo di quanto tu possa mai giustificare, spendere e definire il modo ottimale in cui crescere.

Quando si compila in modalità Debug, la classe di stringhe Standard verificherà gli iteratori e gli indici e, quando richiesto, indicizzerà anche il codice normale. Un char[] farà questo per te? Ne dubito.

Quindi std::string è più veloce, più sicuro e più manutenibile rispetto alle stringhe C. Altre classi offrono ragioni molto simili per essere di gran lunga superiori in ogni modo possibile. Cosa vuoi di più dall'orientamento all'oggetto diverso dalla velocità superiore, dalla correttezza e dalla facilità di manutenzione?

Quindi, quasi per definizione , qualsiasi programma C ++ che sia equivalente al tuo programma C ma che usi OO per gestire le stringhe è intrinsecamente e di gran lunga superiore al tuo programma C.

Il problema che esponi è più facilmente reperibile qui:

I believe to be a much more elegant program.

Credi? Eccezionale. Perché in realtà non torni indietro e controlla ? Perché penso che lo scoprirai, i programmi sono buggati e lenti, e sarebbero notevolmente migliorati da un'applicazione giudiziosa di orientamento agli oggetti solidi. I tuoi sentimenti soggettivi sorgono per ragioni che non hanno nulla a che fare con l'effettiva qualità del programma.

Devi riconoscere che le qualità oggettive di velocità, manutenzione e correttezza di un programma non hanno assolutamente nulla a che fare con la tua opinione soggettiva sul fatto che sia elegante o meno.

E sai cosa? OO, non tutti i problemi vengono affrontati al meglio. C'è un motivo per cui linguaggi come C # hanno lambda e generici, ed è perché l'eredità non è un coltellino svizzero. È solo uno strumento, e ce ne sono altri che servono meglio a determinati scopi. È, tuttavia, uno strumento straordinariamente efficace per molte situazioni, meglio utilizzato per strutturare programmi e moduli.

Is there any projects or problems I can tackle solo?

Sì, molti. Fai un semplice progetto intorno a un argomento di cui sai qualcosa, ad esempio iscriviti agli studenti in un college. Concentrati su una classe come Persona. Ora la persona può essere un professore, un amministratore, uno studente, ecc. Quindi cosa è necessario per mantenere la registrazione per una serie di corsi? Pensare in questo modo può aiutarti a impostare uno scopo per il tuo progetto. Assicurati di coprire circa 5 classi al massimo in modo che tu possa concentrarti sulle tecniche piuttosto che sul business stesso e iniziare ad applicare ciò che sai per creare un'applicazione che risolva il problema. State alla larga dalla GUI di fantasia o dai sofisticati metodi di database poiché non è l'obiettivo. L'obiettivo è di mettere in pratica i concetti OO indipendentemente dal fatto che i dati vengano salvati in un file, in un file XML o in un database.

Un altro modo, e potrebbe essere migliore, è scegliere un libro che usi un esempio in una lingua che ti piace, ad esempio Java o C #. Tali libri avrebbero "OOP" o "Beginning OO" nel titolo. Assicurati di sfogliare il libro e senti di voler andare avanti con esso prima di acquistarlo.

Quando hai compreso le nozioni di base, potresti voler passare a più libri teorici su OO Analysis e OO Design, inclusi i modelli di progettazione.

Per colpire questo da un diverso angolo di attacco, c'è qualcosa che ti impedisce di usare la tua competenza di dominio nella tua professione primaria per scrivere software? Non riesci a immaginare un'applicazione che renderebbe più facile svolgere il tuo attuale lavoro? Non so cosa fa un allenatore sportivo, ma posso immaginare che tenere traccia della progressione delle persone che istruisci e delineare quel progresso potrebbe rivelarsi utile per te e per le persone a cui fai da mentore.

Se costruisci un'app, utilizzando le tecniche OO o altro, otterrai un po 'di esperienza nell'applicazione di tali tecniche. Se ti alleni con un altro amico con competenze di sviluppo del software, inizierai a capire i problemi di ingegneria del software (codice di diramazione e fusione, ad esempio, e problemi di collaborazione con il mondo reale). Se spedisci l'app (offrendola gratuitamente oa pagamento ai colleghi del tuo attuale lavoro), otterrai il resto dell'esperienza necessaria per capire come supportare e mantenere un'applicazione. Mentre mantieni l'applicazione, spero che capirai i punti deboli del tuo progetto iniziale man mano che inizi a soddisfare le richieste di funzionalità e i bug risolti.

Ovviamente, questo presume che non hai urgente bisogno di sostituire il tuo attuale lavoro, ma quando hai finito, avrai o la stoffa per una piccola impresa o abbastanza esperienza per convincere qualcun altro a impiegare te.

Come qualsiasi altro concetto, l'OOP può essere utilizzato in modo improprio. Ho visto molte osservazioni che ha lo scopo di mappare i concetti del mondo reale, e IMHO questo percorso conduce a stati mentali inquietanti dai quali non ci si può aspettare che i soggetti sfuggano, producendo solo schifezze.

È probabile che il tuo gusto sia giusto e che la soluzione non orientata agli oggetti sia migliore. Penso che manchi solo la fiducia.

OOP è intrinsecamente sciocco. Perché scrivere mai un codice "orientato agli oggetti"? Le persone costruiscono anche case orientate al cemento? Automobili orientate alle ruote?

OOP prende uno strumento utile e lo eleva a una religione. Un oggetto può essere molto utile come strumento per aiutarti a definire il tuo programma. Nello stesso modo in cui una ruota è un componente piuttosto utile nella costruzione di un'auto. Non è qualcosa che tutto fa o dovrebbe ruotare attorno al termine "OOP".

Gli oggetti sono utili perché ci consentono di definire i tipi di dati astratti. Possiamo definire una classe che si comporta come il concetto che desideriamo modellare, e che semplifica tutto il codice che manipola questi concetti. Una classe di stringhe è utile perché si comporta come ci si aspetterebbe che una stringa di testo si comporti. Definisce un numero di operazioni che si prevede siano presenti quando si gestiscono stringhe e impedisce altre operazioni prive di senso che sarebbero possibili se si lavorasse sui byte non elaborati che utilizza internamente. Mi permette di pensare sulle stringhe, invece di pensare a matrici e interi, che sono usati internamente per definire la stringa.

Lo stesso dovrebbe valere per gli oggetti che tu stesso definisci. Dovrebbero fornire astrazioni e garanzie e invarianti che ti permettono di dimenticare tutti i dettagli di implementazione. Il punto in una classe è che dovrebbe garantire che non può mai essere "rotto" o portato in uno stato incoerente. Che puoi fare affidamento su di esso per comportarti come il concetto che rappresenta.

Se possiedi alcuni oggetti di questo tipo, puoi utilizzarli come blocchi predefiniti per la tua applicazione.

Ma questo non significa che il tuo codice debba essere "orientato agli oggetti". Ciò non significa che gli oggetti dovrebbero essere il tuo programma, o che tutto deve essere associato a un oggetto.

OOP non è niente di speciale. È un one paradigma di programmazione di molti. C'è la programmazione orientata agli oggetti, c'è la programmazione generica, c'è la programmazione funzionale. Ci sono quelli "di nicchia" come la programmazione logica e quelli "fuori moda" come la programmazione procedurale. Il punto è che, in generale, l'OOP non è "il migliore". Ha alle spalle una potente macchina di marketing, ma questo non lo rende superiore.

Il meglio che puoi fare è cercare di imparare il più possibile per il maggior numero possibile di paradigmi. Quindi usa ciò che ha senso nella lingua in cui stai attualmente lavorando. Alcune lingue rendono l'OOP più facile e tutto il resto più difficile, il che generalmente significa che l'OOP sarà una scelta più attraente. Altri preferiscono FP, e alcuni consentono quasi il qualsiasi paradigma.

Per quanto riguarda i datori di lavoro, i bravi assumeranno persone che sono dei buoni programmatori. I cattivi inseguiranno parole d'ordine. (Conosci OOP? XML? SOAP? TDD? Ottimo, sei assunto!)

Quindi non preoccuparti troppo di renderti attraente per i datori di lavoro. Concentrati sul farti un programmatore migliore. Ciò implica mantenere una mente aperta e sfidare te stesso. Se OOP non ha "cliccato" per te, allora non prendere questo come una scusa per tornare a quello che ti è familiare. Lanciati a nuove sfide. Forse dai un'occhiata a OOP da un'altra angolazione, in una lingua diversa. Forse date un'occhiata alla programmazione funzionale. Cerca di imparare cose nuove, e anche se sembrano inferiori a ciò che già conosci, dai loro una buona possibilità e accetta che la tua impressione iniziale possa essere sbagliata, ma alla fine usa il tuo giudizio. Non c'è un proiettile d'argento, e le tue critiche potrebbero essere perfettamente valide. Basta non usarli come scusa per smettere di imparare.