Come hai ottenuto buone pratiche per i tuoi progetti OOP? [chiuso]

Mi sono reso conto di avere difficoltà a creare progetti OOP. Ho trascorso molto tempo a decidere se questa proprietà è correttamente impostata su classe X.

Ad esempio, questo è un post che ha qualche giorno: /codereview/8041/how-to-improve-my-factory-design

Non sono convinto del mio codice. Quindi voglio migliorare i miei progetti, impiegare meno tempo a crearli.

Come hai imparato a creare buoni progetti? Alcuni libri che mi puoi consigliare?

La progettazione di sistemi è una delle cose che puoi migliorare solo facendo. Ovviamente, aiuta a leggere un po 'di buon design: il libro di design generale orientato agli oggetti è la Banda dei quattro modelli di progettazione: elementi di software riutilizzabile orientato agli oggetti . Ci sono anche altri libri su modelli e principi di progettazione per diversi tipi di sistemi e all'interno di domini diversi.

È anche meglio coinvolgere altre persone. Dopo aver creato un progetto, presentare i problemi che si stanno risolvendo e il progetto ad altre persone per una revisione critica. Ascolta il loro feedback e dialoga con loro, concentrandoti sul perché hai preso le decisioni che hai preso. Mentre stai implementando la soluzione, realizzerai altri problemi con il tuo design. Prendine nota e impara da loro. Potrebbe anche essere una buona idea lavorare con altre persone per rivedere l'implementazione rispetto al design e ai requisiti e avere una discussione critica dei motivi per cui hai fatto le cose che hai fatto.

Anche se in genere trovo che sia meglio sedermi faccia a faccia con altre persone, qui sui programmatori è possibile porre domande specifiche sul design. Esistono anche siti Stack Exchange per revisioni del codice e domande sull'implementazione .

Dagli sguardi della domanda di codereview che hai posto, sei nella fase di esagerare. Penso che sia un problema piuttosto comune tra le persone che scoprono l'importanza di un buon design.

In realtà è un passaggio naturale e probabilmente persino necessario con qualsiasi abilità acquisita. Quando inizi a imparare qualcosa, più avanzi nella conoscenza di un'abilità e più la applichi, migliori sono i risultati e sembra che tu stia andando dritto alla padronanza. Il problema è che il tuo nuovo obiettivo non diventa la qualità dei tuoi risultati, ma quanta conoscenza hai accumulato sulla tua abilità.

La vera padronanza di un'abilità comporta la comprensione di quando usarla e quando non farlo. L'uso eccessivo di tale abilità è probabilmente l'unico modo per sviluppare tale comprensione. Certo, puoi leggere su questo, ma la lettura non è un sostituto dell'esperienza.

Per prima cosa, leggere IMHO è un brutto inizio IMHO. Leggere sui principi di progettazione OO, come SOLID e GRASP è meglio. Dopo averli conosciuti, studiare dei modelli di progettazione comuni è una buona idea, perché vedrai come questi principi possono essere applicati per formare modi di dire concreti.

Si afferma che quando emergono schemi nell'uso di una lingua, la lingua in realtà manca di una caratteristica. Mentre questa affermazione è molto radicale, c'è molta verità in essa. Pertanto, suggerirei di guardare e giocare con altre lingue per comprendere meglio i concetti che stai cercando di utilizzare e anche per conoscere nuovi concetti. Una lista sarebbe Squeak, Ruby e Lisp.
Per quanto riguarda List, la mia raccomandazione personale è la struttura e l'interpretazione dei programmi per computer , che mi ha insegnato molto sul design, mostrandomi quanto si possa facilmente creare soluzioni solide a problemi complessi, con poco più che chiara astrazione e (de) composizione in un modo dall'alto verso il basso.

Quindi ecco cosa suggerisco:

1. scrivere codice (e cercare di capire cosa lo rende negativo)
2. leggi il codice (e cerca di capire cosa lo rende buono)
3. scambiare conoscenze con altre persone. metti alla prova le tue idee.

Come altri hanno già detto, diventerai bravo solo con la pratica e l'esperienza. Non c'è davvero molto di un collegamento che puoi prendere.

Il fatto che tu guardi indietro alle tue cose e non ti piaccia quello che hai scritto, ti mette già davanti alla curva rispetto a molte altre persone nella nostra professione. Mentre stai cercando di migliorare te stesso, il resto di noi lavora con persone che scrivono una funzione a 500 righe con 20 parametri, tutti passati per riferimento e 15 di loro sono [in / out] e quelle persone pensano di essere la bomba perché hanno fatto funzionare quel casino.

Quando si tratta di progettazione software, non è in bianco e nero, o il design è buono o cattivo. Non importa quanta esperienza hai, tornerai ad alcuni dei tuoi vecchi codici e penserai: "cosa stavo fumando quando ho scritto questo?" La chiave è la valutazione costante delle cose e spesso passa attraverso gli esercizi di pensiero per valutare ciò che rende buono il codice buono e cattivo il codice.

Infine, sebbene nulla sostituisca la pratica, è sempre una buona idea continuare a leggere blog / libri / questo sito perché altre persone indicheranno prospettive diverse che potresti non aver considerato.

Per iniziare, consiglierei questi libri:

• Principi, schemi e pratiche agili in C # - Sono 3 / 4o in questo libro. Uno dei punti principali che l'autore sottolinea, e sono d'accordo al 100%, non iniziare a risolvere un problema cercando un modello di progettazione da applicare. Mantieni le cose il più semplici possibile e fai evolvere il codice in un modello, se l'alternativa inizia a diventare più complicata di così.
• Head First Design Patterns - Non ho letto questo libro e in IMO molte serie Head First sono pensate appositamente per i nuovi arrivati ​​sul campo. Quindi tendono ad essere dalla parte più semplice, ma ho sentito / letto molte buone risposte dagli altri su quel libro

Il design frontale non è mai buono come il design posteriore. Basta testare, codificare e refactor. Quando le cose sono brutte e non sei sicuro di come ripulirlo, allora vedi se qualche motivo di design ti aiuterà. Fai pratica per un po 'e presto altri sviluppatori ti chiederanno come realizzare progetti così puliti.