Come definire meglio SRP e oggetti "sani"? [duplicare]

tl; dr Le tue decisioni su quanto astratto dovrebbe dipendere dal tuo problema aziendale per scegliere quanto dividere il bambino.

Comprendere le relazioni e come definirle correttamente senza creare oggetti "divini" è un problema comune quando si progettano soluzioni. La tua idea di compromesso è azzeccata quando stai provando a realizzare qualcosa e il problema diventa, cosa, quando e perché faccio un compromesso. Per prima cosa è necessario avere un buon feeling per definire correttamente le relazioni, design SOLID per così dire.

Ad esempio, hai affermato che un dipendente "possiede" la pausa pranzo, un prodotto "possiede" la sua vendita e un'auto "possiede" la sua accelerazione, ma sono accurate per il tuo problema aziendale. Un dipendente potrebbe aver bisogno di chiedere di poter prendere la pausa pranzo da un sistema BreakManagement, mentre un prodotto potrebbe essere detto in vendita da un sistema CampaignMarketing, o una macchina potrebbe accelerare le ruote, ma non la sua accelerazione rispetto al suolo senza il aiuto del calcolo della trazione. In realtà, devi essere in grado di vedere lo scopo del sistema che stai cercando di costruire e quali entità sono richieste e le relazioni tra quelle entità.

È facile vedere che un dipendente potrebbe aver bisogno di affidarsi a un sistema di gestione delle interruzioni e quella dipendenza per un sistema per la gestione dei dipendenti, ma potrebbe essere una relazione non valida per un sistema che tiene semplicemente traccia delle ore di un dipendente.

Penso che abbiamo imparato molto da quando è stato introdotto SRP, ma in modo più indiretto e generale a causa dei cambiamenti nel modo in cui i progetti di sviluppo software sono gestiti. SRP è un principio che non è stato concepito per avere una serie di regole rigide che potrebbero essere applicate ciecamente a tutte le situazioni. Dipende. Ci sono alcune regole generali che l'esperienza ci ha insegnato che il codice scritto con SRP in mente, tende ad essere più facile con cui lavorare. Qualsiasi cosa può essere presa troppo lontano. Programmare la vita sarebbe molto più facile se mettessimo ogni metodo nella sua classe ogni volta, qualunque cosa. Pessima idea.

La nozione che se i principi SOLID sono applicati correttamente, allora due diversi sviluppatori probabilmente risolverebbero lo stesso problema allo stesso modo, vanificando lo scopo - codice più robusto. Penso che saranno molto vicini, ma non ci dovrebbe mai essere l'aspettativa di essere una coppia perfetta. Quello che dovrebbe accadere è che uno sviluppatore medio dovrebbe essere in grado di guardare entrambe le soluzioni che applicano i principi SOLID "correttamente" e di essere in grado di capire cosa sta facendo il codice nella misura in cui può modificarlo ed estenderlo secondo necessità.

Vorrei anche dire che se due sviluppatori lavorassero con lo stesso utente / cliente, per lo stesso periodo di tempo, passando attraverso tutte le iterazioni e le fasi di un progetto identico, probabilmente finirebbero con disegni simili. Non ci si aspetterebbe che uno sviluppatore inesperto non riesca a produrre un'applicazione simile come sviluppatore senior, ma saremmo in grado di distinguere facilmente la differenza. Sapremmo anche con quale è più facile lavorare - non è questo il motivo?

Sono i requisiti che devono guidare il livello di complessità e astrazione e non solo basati sull'applicazione di un determinato sviluppatore dei principi SOLID. Se costruisco un simulatore di guida per auto e un'accelerazione di base puramente sulle specifiche / medie fornite da qualche servizio di valutazione dell'auto che utilizza condizioni identiche per eseguire i test, non avrei bisogno di molte astrazioni per questa funzionalità. Tuttavia, se i requisiti del mio simulatore dovessero comportare il cambiamento delle condizioni della strada, dell'elevazione, delle condizioni meteorologiche e probabilmente l'usura delle gomme, la maggior parte degli sviluppatori suggerirebbe di non inserire tutto questo codice nella classe Car. Se lo facessi e decidessi di avere diversi tipi di auto, tracce, stagioni, ecc., Lo vedrebbero come un grosso casino che ora ha violato SRP. Non a causa del modo in cui creano le cose individualmente, ma principalmente a causa del cambiamento dei requisiti.