Come esercitarsi nella programmazione orientata agli oggetti? [chiuso]

Ho sempre programmato in linguaggi procedurali e attualmente mi sto muovendo verso l'orientamento agli oggetti. Il problema principale che ho affrontato è che non riesco a vedere un modo per praticare l'orientamento agli oggetti in modo efficace. Spiegherò il mio punto. Quando ho imparato PHP e C era abbastanza facile da esercitarsi: era solo questione di scegliere qualcosa e pensare a un algoritmo per quella cosa.

In PHP, ad esempio, era questione di sedersi e pensare: "bene, solo per esercitarmi, lasciami costruire un'applicazione con un'area di amministrazione in cui le persone possano aggiungere prodotti". È stato abbastanza facile, si trattava di pensare a un algoritmo per registrare un utente, accedere all'utente e aggiungere i prodotti. Combinandoli con le funzionalità di PHP, è stato un buon modo per esercitarsi.

Ora, nell'orientamento agli oggetti abbiamo molte altre cose. Non si tratta solo di pensare a un algoritmo, ma di analizzare i requisiti più in profondità, scrivere casi d'uso, capire diagrammi di classe, proprietà e metodi, impostare l'iniezione delle dipendenze e molte altre cose.

Il punto principale è che nel modo in cui sto imparando l'orientamento agli oggetti sembra che un buon design sia cruciale, mentre nei linguaggi procedurali era sufficiente una vaga idea. Sto Non dicendo che in linguaggi procedurali possiamo scrivere un buon software senza disegno, solo che per amor di praticare è fattibile, mentre in orientamento oggetto non sembra possibile andare senza un buon progetto, anche per la pratica.

Questo sembra essere un problema, perché se ogni volta che ho intenzione di esercitarmi ho bisogno di capire tonnellate di requisiti, casi d'uso e così via, sembra non essere un buon modo per migliorare l'orientamento agli oggetti, perché ciò richiede di avere un'idea completa per un'app ogni volta che vado a esercitarmi.

Per questo motivo, qual è un buon modo per esercitarsi nell'orientamento agli oggetti?

Ora, nell'orientamento agli oggetti abbiamo molte altre cose.

No tu non ...

Non si tratta solo di pensare a un algoritmo, ma di analizzare i requisiti più in profondità, scrivere casi d'uso, capire diagrammi di classe, proprietà e metodi, impostare l'iniezione delle dipendenze e molte altre cose.

Nessuna di queste cose è necessaria per praticare la programmazione orientata agli oggetti.

È stato abbastanza facile, si trattava di pensare a un algoritmo per registrare un utente, accedere all'utente e aggiungere i prodotti.

Tutta la programmazione orientata agli oggetti è invece di pensare agli algoritmi per fare questi passaggi, pensi a quali oggetti sono necessari per fare questi passi - quale funzionalità vuoi, quale stato è necessario per farlo e che tipo di interfaccia vuoi esporre per l'utente. Proprio come devi fare nella programmazione procedurale.

L'unica differenza è che invece di concentrarti sulle funzioni di cui hai bisogno e su come funzionano, ti concentri su come la funzionalità e lo stato sono raggruppati in responsabilità e su come queste responsabilità interagiscono.

Come esercitarsi? Allo stesso modo in cui pratichi la programmazione procedurale: scegli un problema e risolvi il problema usando fasci di classi. Scopri come ha funzionato, ripeti con le lezioni apprese.

Buona domanda. Naturalmente, ciò che stai dicendo è che praticare OOP in realtà significa praticare tutte queste cose (analisi dei requisiti, casi d'uso, modelli di progettazione, ecc.), Il che è vero e all'inizio può sembrare scoraggiante.

Il mio consiglio sarebbe di iniziare le sessioni di pratica tenendo a mente due cose: lo sviluppo guidato dai test e il principio della responsabilità singola .

Quindi inizia come hai fatto con PHP / C: inventati un'idea, pensa a cosa ti serve e implementa queste cose una dopo l'altra. Tuttavia, tieni presente che devi iniziare dai test (che ti costringono a definire interfacce appropriate, poiché altrimenti la testabilità subisce immediatamente) e che TDD implica un ciclo di rifattore rosso-verde. In altre parole, hai un po 'di funzionalità e, una volta che funziona, rifletti per ottenere un corretto design OO se non lo hai fatto dall'inizio (cosa che non vorrai).

Quando si esegue questa fase di refactoring, ricordarsi sempre dell'SRP. Se hai aggiunto una seconda responsabilità al tuo oggetto, è tempo di creare qualcosa di nuovo.

Quando ti sviluppi in questo modo, devi essere consapevole che la tua soluzione finale sarà molto diversa da quella con cui inizi. La tua curva di apprendimento sarà anche piuttosto ripida. Ad esempio, non imparerai cos'è un modello Factory, ma riconoscerai invece la necessità di qualcosa che crea istanze della tua classe in diversi modi. Quindi, se non hai mai sentito parlare di modelli di design orientati agli oggetti, è bene leggere un po 'su quelli in parallelo.

Se stai iniziando con OOP, puoi divertirti e "esercitarti" offline guardando praticamente qualsiasi sistema del mondo reale e considerando quali sono gli oggetti e quale sia la loro relazione e quali metodi / interfacce potrebbero supportare e come li rappresenteresti in una gerarchia di classi e come una raccolta di oggetti istanziati e quali sarebbero le relazioni di proprietà degli oggetti e così via (nota: non menziono affatto la parola "algoritmi" in precedenza). Disegna molti diagrammi (impara un po 'di UML o simili) prima di pensare a scrivere codice.

Questo ti aiuterà a sviluppare un senso molto migliore delle relazioni IS-A e HAS-A , che è probabilmente la singola classificazione più importante in qualsiasi progetto OOP (e nonostante ciò, sembra ancora essere qualcosa con cui molti programmatori di linguaggio OOP stagionati lottano con ). Se padroneggi IS-A / HAS-A c'è anche IS-IMPLEMENTED-IN-TERMS-OF (che ho anche visto descritto come IS-KIND-OF-A: ^)

Seriamente, il prossimo viaggio al supermercato, immagina che qualcuno ti abbia dato il compito di scrivere una simulazione OOP del luogo ...

Quello che ricordo dai miei tempi in C (molto lontano nel passato), eravamo soliti separare funzioni e procedure in diversi file in base alla loro responsabilità. Non sto affermando che sia perfetto o altro, ma è stato un buon punto di partenza per quando ho effettivamente iniziato a programmare in linguaggi orientati agli oggetti. Quindi forse potresti iniziare con la conversione di file in oggetti.

Per quanto riguarda OOP, si tratta davvero di pratica e ricerca del miglioramento. Raramente qualcuno lo capisce da zero. Pertanto, le iterazioni avvengono durante il ciclo di vita del progetto.

Aggiungiamo alcuni termini, l'analisi orientata agli oggetti e progettazione orientata agli oggetti , come ha fatto Peter Coad nel 1990.

Insieme formano una disciplina di ingegneria del software OOAD che può (fatto bene) supportare il programmatore nel momento in cui scrivo e collaudo il codice. La programmazione orientata agli oggetti può quindi avere il suo corretto livello di granularità, un uso abile delle caratteristiche del linguaggio di programmazione per soddisfare gli obiettivi funzionali e i requisiti di progettazione specificati a livello di progetto.

A volte è un progetto individuale, quindi devi indossare tutti i cappelli (ma non necessariamente tutti allo stesso tempo). Sono un grande fan dello sviluppo guidato dai test per i miei progetti personali (vedi la raccomandazione di Frank), ma non riguarda solo lo sviluppo di software orientato agli oggetti.

In un progetto di gruppo avere una buona divisione delle responsabilità è la chiave per un'implementazione di successo. L'uso abile di modelli di progettazione orientati agli oggetti aiuta la comprensione del team limitando le interfacce visibili necessarie per analisi, feed di dati e logica aziendale per condividere un framework utilizzabile.

"bene, solo per esercitarmi, lasciami costruire un'applicazione con un'area di amministrazione in cui le persone possano aggiungere prodotti". È stato abbastanza facile, si trattava di pensare a un algoritmo per registrare un utente, accedere all'utente e aggiungere i prodotti.

Perché non fare la stessa cosa solo questa volta con oggetti utente e oggetti prodotto? Inoltre, se si utilizza un linguaggio che supporta sia procedurale che OO, è possibile provare a implementare oggetti basati sulla libreria procedurale standard, come un oggetto file.