Domanda di progettazione OOP

In "Fatti e errori dell'ingegneria del software", Robert Glass afferma che il riutilizzo del codice nel piccolo è un problema risolto, cioè è relativamente facile scrivere funzioni riutilizzabili per compiti semplici e ben definiti.

Ma Glass dice anche che il riutilizzo del codice nel grande è un problema irrisolto. Prendo questo per significare che non esiste una regola ferrea sul riutilizzo del codice. L'unica risposta è:

• Applica il giudizio e l'esperienza il meglio che puoi.
• Prototipo rapidamente.
• Sii pronto a refactoring, se necessario.

Molti progetti cercano di semplificare lo spazio dei problemi formulando ipotesi o imponendo "convenzioni", ma queste semplificazioni sacrificano inevitabilmente alcune funzionalità di cui potresti aver bisogno.

Guarda l'approccio che i ragazzi del progetto Doctrine stanno predicando. Questo ha risposto a molte domande per me quando ho sofferto con l'architettura PHP che trattava gli elementi del database.

Potresti voler pensare al futuro (ma non lasciarti trasportare troppo). Ci sarà sempre un momento in cui vorrete cambiare il database rdbms, o magari passare a un cluster di server. Che cosa influenza cambi del genere sul tuo codice? Cosa succede se il database deve essere normalizzato e le definizioni delle tabelle cambiano? Il codice sarà facilmente modificabile per adattarsi ai nuovi requisiti, o sarà molto noioso scrub l'SQL in molti file nel codice.

Ci sono dei compromessi per ogni scelta di design, e non c'è sempre un modo giusto o sbagliato. devi solo pensare alla tua applicazione e a cosa potrebbe essere importante.

Niente è gratuito, la scelta dipende da te.

Voglio velocità, codificare tutto in assembler. Se hai bisogno di flessibilità, usa le librerie framework, fai il rollup delle tue interfacce.

Rendo sempre il mio codice riusabile e quando arriva il momento , ottimizza (abilita APC, ricarica automaticamente cache, refactor, compila come modulo PHP ecc.).