Mi sono reso conto di avere difficoltà a creare disegni OOP. Ho passato molto tempo a decidere se questa proprietà è impostata correttamente sulla classe X.
Ad esempio, questo è un post che ha alcuni giorni: link
Non sono convinto del mio codice. Quindi voglio migliorare i miei progetti, impiegare meno tempo a crearlo.
Come hai imparato a creare buoni design? Alcuni libri che mi puoi consigliare?
Progettare i sistemi è una delle cose che puoi migliorare solo facendo. Certo, aiuta un po 'a leggere sul buon design - il consiglio generale di design orientato agli oggetti è il consiglio di amministrazione di Gang of Four Design Pattern: elementi del software orientato agli oggetti riutilizzabile . Esistono anche altri libri su modelli e principi di progettazione per diversi tipi di sistemi e all'interno di diversi domini.
È anche meglio coinvolgere altre persone. Dopo aver creato un design, presentare il problema (i) che si sta risolvendo e il design ad altre persone per una revisione critica. Ascolta i 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. Prendi nota di questi 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 sui motivi per cui hai fatto ciò che hai fatto.
Anche se in genere trovo il modo migliore per sedermi con altre persone faccia a faccia, è possibile porre domande specifiche sul design qui su Programmers. Esistono anche siti Stack Exchange per revisioni del codice e implementazione domande.
Dall'aspetto della domanda sulla schermata del codice che hai chiesto, sei nella fase di strafare. Penso che sia un problema piuttosto comune tra le persone che scoprono l'importanza del buon design.
In realtà è un passo naturale e probabilmente anche necessario con qualsiasi abilità che raccogli. Quando inizi a imparare qualcosa, più avanzi nella conoscenza di un'abilità e più la applichi, migliori sono i tuoi risultati e sembra che tu sia diretto verso la maestria. Il problema è che il tuo nuovo target non diventa la qualità dei tuoi risultati, ma quanta conoscenza hai accumulato sulla tua abilità.
La vera padronanza di un'abilità implica la comprensione di quando usarla e quando no. Abusare di quell'abilità è probabilmente l'unico modo per sviluppare tale comprensione. Certo, puoi leggere su questo, ma leggere non è un sostituto per l'esperienza.
Per prima cosa, leggere gli schemi di progettazione è un brutto inizio. IMHO. Leggere i principi di progettazione OO, come SOLID e GRASP è migliore. Dopo averli conosciuti, studiare gli schemi di progettazione comuni è una buona idea, perché vedrai come questi principi possono essere applicati per formare idiomi concreti.
Si sostiene che quando i modelli emergono nell'uso di una lingua, la lingua in realtà manca di una caratteristica. Mentre questa affermazione è molto radicale, c'è molta verità in essa. Quindi suggerirei, guardate e giocherete con altre lingue per ottenere una migliore comprensione dei concetti che state cercando di impiegare, e anche per conoscere nuovi concetti. Una lista dei preferiti sarebbe Squeak, Ruby e Lisp.
Per quanto riguarda List, la mia raccomandazione personale è Struttura e interpretazione dei programmi per computer , che mi ha insegnato molto sul design, dimostrandomi in che modo è possibile creare soluzioni robuste a problemi complessi, con poco più di una chiara astrazione e (de) composizione dall'alto verso il basso.
Quindi ecco cosa suggerisco:
Come altri hanno già detto, diventerai bravo solo con la pratica e l'esperienza. Non c'è davvero una scorciatoia che puoi prendere.
Il fatto che tu guardi alle tue cose e che 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 di 500 righe con 20 parametri, tutti trasmessi per riferimento e 15 di loro sono [in / out] e quelle persone pensano di essere la bomba perché hanno fatto funzionare quel pasticcio.
Quando si tratta di progettazione di software, non è in bianco e nero, né il design è buono o cattivo. Non importa quanta esperienza hai, tornerai ad un vecchio codice e penserai: "Cosa stavo fumando quando ho scritto questo?" La chiave è la valutazione costante delle cose e frequentemente durante gli esercizi di pensiero per valutare ciò che rende il codice buono e il codice cattivo male.
Infine, anche se nulla sostituisce 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:
Il design all'avanguardia non è mai buono come il design esterno. Solo test, codice e refactoring. Quando le cose sono brutte, e non sei sicuro di come ripulirlo, allora vedi se qualche schema di progettazione ti sarà d'aiuto. Pratica questo per un po 'e presto altri sviluppatori ti chiederanno come ti viene proposto un design così pulito.
Leggi altre domande sui tag object-oriented design