Apprendimento del buon design OOP e disimparare alcune cattive abitudini [duplicato]

1

Sono stato in gran parte un programmatore C finora nella mia carriera con la conoscenza del C ++. Mi affido principalmente al C ++ per la comodità che STL offre e non mi concentro quasi mai su buone pratiche di progettazione. Come ho iniziato a cercare una nuova posizione lavorativa, questa mia cattiva abitudine è tornata a tormentarmi. Durante le interviste, mi è stato chiesto di progettare un problema (come gli scacchi, o qualche altro scenario) usando OOP e lo sto facendo davvero male (ne sono venuto a conoscenza attraverso il feedback di un'intervista).

Ho provato a fare cose su Google e ho trovato così tante opinioni e libri correlati che non so da dove cominciare. Ho bisogno di una buona introduzione al design OOP con cui posso imparare il design pratico, non solo la teoria.

Puoi indicarmi un libro che soddisfi i miei requisiti? Preferisco il C ++, ma qualsiasi altra lingua va bene finché riesco a individuare le buone pratiche.

Inoltre, so che i libri non possono che andare così lontano. Gradirei anche qualsiasi idea di progetto di buone pratiche che ti abbia aiutato a imparare e migliorare i tuoi concetti OOP.

    
posta TinkerTanner 30.10.2012 - 19:17
fonte

6 risposte

4

Per quanto riguarda la formazione, suggerisco di andare a link e osservarli. Riguardano idee molto importanti.

Dopo aver guardato i video, dai un'occhiata a Head First Design Patterns. Che ti guida attraverso una serie di problemi e soluzioni.

Non ho suggerimenti specifici sul progetto, ma ti consiglierei di provare qualsiasi progetto in un linguaggio strettamente orientato agli oggetti come Java. C + +, facciamo in modo che tu possa imbrogliare troppo facilmente, e forse anche senza sapere che lo stai facendo.

    
risposta data 30.10.2012 - 19:28
fonte
3

(IMO) Non ci sono grandi libri sulla progettazione del software. Molti dei libri di modelli (preferisco l'originale , ma ho sentito cose positive su alcuni altri) sono abbastanza buoni per ottenere la terminologia e consolidare i concetti, ma dovrebbero essere utilizzati solo dopo un po 'di pratica. Senza la pratica, i programmatori tendono a sovra-applicare i modelli di progettazione o a fraintendere i problemi che i modelli impediscono.

Per quanto riguarda i problemi di pratica, ti consiglio qualcosa che hai già fatto per iniziare. Quindi capisci il dominio e cosa dovrebbe fare e puoi concentrarti solo sul design. Principalmente sebbene tu abbia solo bisogno di iterare. Progettare un programma, implementarlo, vedere come funziona (e non). Crea un nuovo design con le lezioni apprese per un nuovo problema, ripeti.

Il design del programma è una di quelle cose che finisce per essere più artigianale che scientifico. Continua a farlo e diventerai progressivamente migliore.

    
risposta data 30.10.2012 - 19:27
fonte
2

Il libro 'Head First Design Patterns' menzionato nella risposta Ben è eccellente. Porta davvero alla vita le idee del progetto originale "Gang of Four".

Poiché nella risposta è Telastyn , la comprensione del dominio è fondamentale e questo aiuterà davvero a informare il modello dell'oggetto . Per questo consiglio vivamente il Domain Driven Design di Eric Evans . Ha anche una grande bibliografia di libri su OO.

Infine, il tuo approccio ai test informerà sul modo in cui progetta il tuo software e su quali modelli OO utilizzi.

Non ho davvero ottenuto "Factory Pattern" fino a quando non ho dovuto scrivere un test unitario per un codice legacy che nel suo costruttore ha creato una delle sue dipendenze.

Ciò ha reso molto difficile il test e mi ha spinto a rifattorizzare il codice per fare in modo che la dipendenza creata da una factory durante l'esecuzione dei test potesse essere impostata per restituire un oggetto fittizio.

    
risposta data 30.10.2012 - 20:54
fonte
2

Un ottimo libro sull'argomento è Euristica di progettazione orientata agli oggetti . Il libro contiene oltre 60 euristiche indipendenti dalla lingua. Oltre alla teoria, il libro ha un'appendice di 122 pagine di esempi C ++. Non posso raccomandare abbastanza questo libro, è un'ottima introduzione.

È un po 'più difficile leggere, ma Applicare UML e pattern è anche un'ottima introduzione. Questo libro è enorme e non è una lettura veloce, ma utilizza due casi studio per presentare il materiale (il gioco del monopolio e un sistema di punti vendita).

Questi due libri (e Refactoring ) sono 3 delle maggiori influenze nella mia carriera di programmatore. Non rimarrai deluso.

    
risposta data 30.10.2012 - 23:51
fonte
1

Penso che i Principi, schemi e pratiche agili di Uncle Bob siano davvero un buon libro per te. Il libro usa C # per molti esempi, ma pensa a quegli esempi come pseudo-codice piuttosto che come produzione C #. Tutto ciò che il libro insegna può essere facilmente applicato a qualsiasi linguaggio OO e il livello del materiale sarà probabilmente perfetto per te.

Mentre tu sei nuovo e stai imparando, ti consiglio vivamente di stare lontano dai libri sui "modelli di progettazione". Troppe persone le raccolgono, imparano alcuni modelli e iniziano a schiaffeggiarle dappertutto. Come sottolinea lo zio Bob nel libro sopra riportato, dovresti inserire un codice in uno schema quando ne vedi uno in via di sviluppo, piuttosto che iniziare con l'obiettivo di costruire un modello specifico in primo luogo. Tuttavia, hai bisogno di un buon senso OOP prima di poter prendere una decisione di progettazione che ti porterebbe a un modello.

Per quanto riguarda il materiale al di fuori dei libri, direi imparare i principi SOLID, KISS e DRY. E quando dico "impara", non intendo leggere su di loro e pensare di capirli. Voglio dire, quando codifichi, vivi e respira quei principi. Ogni volta che aggiungi un'altra funzione o un'altra variabile continua a chiederti:

  • sto duplicando il codice esistente?
  • La mia funzione / classe fa troppe cose?
  • Può ciò che ho appena scritto essere più semplice?
  • ....

Come menzionato @worldofchris (+1 a quella risposta), consiglierei anche di imparare TDD mentre stai imparando OO. I due vanno di pari passo e il codice ben progettato, si presterà per essere facilmente testabile. Viceversa, se il tuo codice è già testabile, la sua qualità tenderà ad essere più elevata in relazione al codice che non ha copertura di test unitario.

    
risposta data 30.10.2012 - 23:02
fonte
1
  • Pulisci codice

  • Programmatore pragmatico

  • Utilizzo del codice legacy

La maggior parte dei libri ti farà sentire felice. Questo non ti procurerà un lavoro.

Inizia leggendo alcuni capitoli di Pragmatic Programmer e poi passa a Clean Code. Esamina il tuo vecchio codice mentre leggi i libri e avvia il refactoring.

Leggere libri non ti darà esperienza, ma rendere il tuo codice "pulito" lo farà. Sta a te decidere quando tracciare la linea relativa alla qualità del tuo codice.

Il motivo per cui raccomando questi libri è perché i ragazzi che li hanno scritti lavorano in questo settore da decenni e hanno una buona idea di cosa funziona e cosa no.

    
risposta data 30.10.2012 - 23:51
fonte