Ho visto un sacco di conferenze su Clojure e programmazione funzionale di Rich Hickey e alcune delle conferenze di SICP, e sono venduto su molti concetti di programmazione funzionale. Ho incorporato alcuni di essi nel mio codice C # in un lavoro precedente, e per fortuna è stato facile scrivere codice C # in uno stile più funzionale.
Al mio nuovo lavoro usiamo l'ereditarietà di Python e multiple è di gran moda. I miei collaboratori sono molto intelligenti, ma devono produrre codice in fretta data la natura della compagnia. Sto imparando sia gli strumenti che il codice base, ma anche l'architettura stessa mi rallenta. Non ho scritto la gerarchia di classi esistente (né potrei ricordare tutto su di esso), e così, quando ho iniziato ad aggiungere una funzionalità abbastanza piccola, ho capito che dovevo leggere molto codice nel processo. In superficie il codice è ben organizzato e suddiviso in piccole funzioni / metodi e non copia-incolla-ripetitivo, ma il rovescio della medaglia non è ripetitivo è che c'è qualche funzionalità magica nascosta da qualche parte nella catena gerarchica che unisce magicamente le cose insieme e funziona a mio nome, ma è molto difficile da trovare e da seguire. Ho dovuto accendere un profiler ed eseguirlo attraverso diversi esempi e tracciare il grafico di esecuzione e passare un debugger un paio di volte, cercare il codice per alcune sottostringhe e solo leggere pagine al momento. Sono abbastanza sicuro che una volta fatto, il mio codice risultante sarà breve e ben organizzato, e tuttavia non molto leggibile.
Ciò che scrivo si sente dichiarativo, come se stessi scrivendo un file XML che guida un altro motore magico, tranne per il fatto che non esiste una documentazione chiara su come dovrebbe essere l'XML e su cosa fa il motore eccetto per gli esempi esistenti che io può leggere oltre al codice sorgente per il 'motore'.
Ci deve essere un modo migliore. L'IMO che usa la composizione sull'ereditarietà può aiutare un bel po '. In questo modo il calcolo sarà lineare anziché saltare su tutto l'albero della gerarchia. Ogni volta che la funzionalità non si adatta perfettamente a un modello di ereditarietà, dovrà essere deformata per adattarsi, o l'intera gerarchia di ereditarietà dovrà essere sottoposta a refactoring / ribilanciamento, una specie di albero binario sbilanciato che necessita di rimodellare di volta in volta in ordine per migliorare il tempo medio di ricerca.
Come ho detto prima, i miei collaboratori sono molto intelligenti; hanno semplicemente fatto le cose in un certo modo e probabilmente hanno la capacità di tenere un sacco di cazzate non legate nella loro testa in una volta.
Voglio convincerli a dare una composizione e un approccio funzionale a quello OOP. Per farlo, ho bisogno di trovare del materiale molto buono. Non credo che una conferenza SCIP o una di Rich Hickey lo farà - temo che verrà contrassegnato come troppo accademico. Quindi, semplici esempi di classi Dog and Frog e AddressBook non connivono in un modo o nell'altro: mostrano come l'ereditarietà possa essere convertita in composizione ma non perché sia realmente e obiettivamente migliore.
Quello che sto cercando è un esempio di codice reale che è stato scritto con molta ereditarietà, poi ha colpito un muro e riscritto in uno stile diverso che usa la composizione. Forse c'è un blog o un capitolo. Sto cercando qualcosa che possa riassumere e illustrare il tipo di dolore che sto attraversando.
Ho già lanciato l'espressione "composizione sull'eredità", ma non è stata accolta con entusiasmo come speravo. Non voglio essere percepito come un nuovo ragazzo a cui piace lamentarsi e colpire il codice esistente mentre cerca un approccio perfetto pur non contribuendo abbastanza velocemente. Allo stesso tempo, il mio istinto è convinto che l'eredità sia spesso lo strumento del male e voglio mostrare un modo migliore in un prossimo futuro.
Sei incappato in grandi risorse che possono aiutarmi?