Applica il Refactoring di singola responsabilità nell'app form

Non sei sicuro del motivo per cui hai problemi a vedere lo split

//responsibility : contain the data from a spreadsheet
public class SpreadSheet
{
    public Row[] Rows {get;set;}
}

//responsibility : load spreadsheets from a data source
public class SpreadSheetLoader : ISpreadSheetLoader
{
    public SpreadSheet Load(string filename)
}

//responsibility : search a spreadsheet and return the results
public class SpreadSheetSearcher
{
    public SearchResult SearchSpreadSheet(SpreadSheet spreadsheet, string searchstring);
}

//responsibility :: join the view (form) to the models (business object defined above)
public class myApp
{
    LoadButtonClick()
    {
         this.spreadSheet = this.spreadSheetLoader.Load(this.txt_filename)
         this.spreadSheetDataGrid.Load(this.spreadSheet)
    }
    SearchButtonClick()
    {
         this.searchResults = this.spreadSheetSearcher(this.spreadSheet, this.txt_searchstring)
         this.resultDatagrid.Load(this.searchResults)
    }
}

Commento preliminare

Il principio di responsabilità singola si applica a classi e moduli. Non si tratta di funzionalità, ma di motivi per cambiare (come spiegato nell'articolo collegato da Uncle Bob). In altre parole, non è tanto la responsabilità di della classe, quanto la responsabilità di ciò che fa la classe.

La progettazione funziona bene

La tua domanda riguarda più le funzioni e il principio fai-da-una-cosa-e-fai-bene :

• nella funzione di caricamento si fanno due cose molto diverse: scoprire cosa caricare (interazione dell'utente in attesa di utente) e caricare i dati (operazione tecnica che può essere eseguita in background senza attendere).
• nella funzione del tuo processo, fai anche due cose diverse. Il primo è un calcolo complesso (il nucleo dell'elaborazione) il secondo è l'output del risultato.

La chiave qui è la manutenibilità e il riutilizzo:

• E se un giorno decidessi di caricare un file predefinito all'avvio, in silenzio, senza disturbare l'utente? Con la tua struttura, dovresti riscrivere una seconda funzione di caricamento, quindi non utilizzare più DRY. E avresti quindi due funzioni da mantenere, se la struttura dei dati dovesse cambiare.
• e se un giorno avresti eseguito la migrazione della tua app a Windows 25 con un'API completamente rinnovata (ad esempio le finestre di dialogo con comando vocale che sostituiscono i dialoghi dello schermo)? Con la tua struttura, gli specialisti dell'interfaccia utente dovrebbero passare attraverso due funzioni eterogenee, cercando di capire cos'è l'interfaccia utente e cosa rimane invariato.

Ecco perché fare una cosa è così importante. È un modo per trarre vantaggio dalla separazione delle preoccupazioni.

Ma come possiamo ottenere qualcosa di complesso, se le funzioni fanno una cosa?

D-O-T ha un altro principio chiave: avere un solo livello di astrazione in ogni funzione. Entrambi i principi devono essere considerati insieme.

Questo significa che puoi avere una funzione che fa una cosa complessa come ad esempio "caricare un file scelto dall'utente". Ma questa cosa complessa sarebbe scomposta in due cose meno complesse a un livello più basso di astrazione, chiedendo (UI) e caricando (file di lettura). Ciascuno sarebbe quindi implementato in una funzione di livello inferiore che fa-one-thing-and-do-it-well.