Flup è diretto nella giusta direzione. Il "principio della responsabilità unica" si applicava originariamente alle procedure. Ad esempio, Dennis Ritchie direbbe che una funzione dovrebbe fare una cosa e farlo bene. Quindi, in C ++, Bjarne Stroustrup direbbe che una classe dovrebbe fare una cosa e farlo bene.
Si noti che, ad eccezione delle regole empiriche, questi due hanno formalmente poco o nulla a che fare l'uno con l'altro. Si rivolgono solo a ciò che è conveniente esprimere nel linguaggio di programmazione. Bene, questo è qualcosa. Ma è una storia alquanto diversa da quella che sta guidando Flup.
Le implementazioni moderne (ovvero, agili e DDD) si concentrano più su ciò che è importante per l'azienda che su ciò che il linguaggio di programmazione può esprimere. La parte sorprendente è che i linguaggi di programmazione non hanno ancora raggiunto. I vecchi linguaggi simili a FORTRAN catturano responsabilità che si adattano ai principali modelli concettuali dell'epoca: i processi che uno applicava a ciascuna carta mentre passava attraverso il lettore di carte o (come in C) l'elaborazione che accompagnava ogni interruzione. Poi vennero le lingue ADT, che erano maturate al punto da catturare ciò che il DDD avrebbe poi reinventato come importante (anche se Jim Neighbours aveva scoperto, pubblicato e utilizzato la maggior parte di questo nel 1968): ciò che oggi chiamiamo classi . (NON sono moduli.)
Questo passaggio è stato meno un'evoluzione di un'oscillazione del pendolo. Man mano che il pendolo passava ai dati, abbiamo perso la modellazione dei casi d'uso inerente a FORTRAN. Va bene quando il tuo focus principale riguarda i dati o le forme su uno schermo. È un ottimo modello per programmi come PowerPoint, o almeno per le sue semplici operazioni.
Ciò che si è perso sono le responsabilità del sistema . Non vendiamo gli elementi di DDD. E non conosciamo bene i metodi di classe. Vendiamo responsabilità di sistema. Ad un certo livello, è necessario progettare il sistema in base al principio della responsabilità singola.
Quindi, se guardi persone come Rebecca Wirfs-Brock, o me, che parlavano di metodi di classe, ora parliamo di casi d'uso. Questo è ciò che vendiamo. Quelle sono le operazioni di sistema. Un caso d'uso dovrebbe avere un'unica responsabilità. Un caso d'uso è raramente un'unità architettonica. Ma tutti cercavano di fingere che lo fosse. Testimone del popolo SOA, per esempio.
Questo è il motivo per cui sono entusiasta dell'architettura DCI di Trygve Reenskaug, che è quella descritta nel libro Lean Architecture sopra. Finalmente dà una certa statura a quello che era un arbitrario e mistico obbedimento alla "singola responsabilità" - come si trova nella maggior parte delle argomentazioni di cui sopra. Quella statura si riferisce a modelli mentali umani: prima gli utenti finali e poi i programmatori. Si riferisce a problemi commerciali. E, quasi per caso, incapsula il cambiamento mentre il flup ci sfida.
Il principio della responsabilità singola, come lo conosciamo, è o un dinosauro rimasto dai suoi giorni di origine o un cavallo da hobby che usiamo come sostituto della comprensione. Devi lasciare alcuni di questi cavalli per hobby per fare un ottimo software. E questo richiede pensare fuori dagli schemi. Mantenere le cose semplici e facili da capire funziona solo quando il problema è semplice e facile da capire. Non sono terribilmente interessato a quelle soluzioni: non sono tipiche e non è dove sta la sfida.
