Confuso sul principio di responsabilità singola nel seguente esempio

Question

Nel seguente video , l'autore prende una classe esistente e assegna il Single Principio di responsabilità ad esso. Prende una classe di stampa che ha il compito di accedere ai dati, formattare e stampare il rapporto. Suddivide ciascun metodo nella propria classe, quindi crea una classe DataAccess per gestire l'accesso ai dati, crea una classe ReportFormatter per gestire la formattazione del report e crea una classe ReportPrinter per gestire la stampa del report. La classe Report originale viene quindi lasciata con un metodo, Print () che chiama il metodo della classe ReportPrinter Print. DataAccess e ReportFormatter sembrano avere responsabilità, ma ReportPrinter si affida a DataAcess e ReportFormatter, quindi questo non rompe l'SRP o lo sto fraintendendo?

Answer 1

Il principio di responsabilità singola indica che una determinata classe dovrebbe avere un'unica responsabilità (o "motivo per cambiare"). Non indica di per sé come debba essere soddisfatta tale responsabilità. Ciò può, e spesso richiede, la collaborazione di più altre classi come collaboratori.

Answer 2

Senza guardare il video, sembra un design ragionevole. SRP non viene interrotto, poiché i metodi relativi all'accesso ai dati non vengono visualizzati nella classe ReportPrinter, solo il concetto che "posso chiamare qualcosa per ottenere i dati desiderati."

Potresti spingerlo un po 'oltre e avere una classe coordinatore responsabile solo del coordinamento delle attività della classe di accesso ai dati, della classe formatter e della classe printer. È inoltre possibile disporre gli oggetti in diversi modi, ad esempio se il coordinatore invia i dati al formatter, che li invia alla stampante e il coordinatore non (direttamente) conosce la stampante.

Qualcosa deve sapere sul coordinamento degli sforzi degli oggetti a fuoco ristretto. Questa diventa la loro responsabilità. Va bene conoscere l'idea o il concetto di ciò che faranno gli altri oggetti, purché tu non sappia o ti interessi di come . Pensare alle interfacce come "cuciture di responsabilità" è un buon inizio.

Può anche essere utile se pensi agli oggetti come a scambiarsi dati invece di "fare". cose. Quindi ReportFormatter restituisce (o inoltra) un nuovo oggetto che rappresenta un report formattato, anziché eseguire (concettualmente) oggetti su un report esistente.

Answer 3

SRP non risolve le dipendenze. Suddividere la classe in classi a responsabilità singola faciliterà in seguito la separazione di tali dipendenze. SRP affronta uno dei due principi citati insieme: coesione e accoppiamento. L'SRP riguarda l'alta coesione e le dipendenze possono essere indicative di un elevato accoppiamento. I buoni design hanno un'elevata coesione e un basso accoppiamento. A volte questi due principi possono essere in contrasto.

Answer 4

No. Non rompe SRP.

Supponi che

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

Evento sebbene ReportPrinter si basi su DataAccess e ReportFormatter , qualsiasi modifica nel contratto di IDataAccess o IReportFormatter dovrebbe essere implementata da DataAccess e ReportFormatter rispettivamente. ReportPrinter non si preoccupa dei cambiamenti di responsabilità in tali classi.

Puoi avere Composizione o implementare Mediatore per fornire sciolto accoppiamento tra queste tre classi e lavoro svolto. Tieni accoppiamento lontano da responsabilità .