Devo separare nella propria classe quando si creano metodi privati nel livello di servizio?

Question

Devo separare nella propria classe quando si creano metodi privati nel livello di servizio?

#1 da (2 voti)

0

Desidero che il mio progetto rispetti i principi SOLID e scriva codice pulito, ma non sono ancora molto chiaro quando dovrei separarmi dal livello di servizio.

Ho un controller Web Api 2.0 chiamato ParkingController che ha il seguente metodo:

public List<Week> GetParkingPlaces(DateTime date)
{
    date = DateTime.Now.ToWesternEuropeStandardTime().Date;
    return _service.GetWeeks(date);
}

E i metodi di servizio:

public List<Week> GetWeeks()
{
    // About 10 lines of logic here, calling CreateDaysInWeek and looping here
    return weeks;
}

private Week CreateDaysInWeek(DateTime startOfWeek, List<ParkingPlace> parkingPlaces)
{
    // About 10 lines of logic to Create days in week.
    return new Week(daysInWeek);
}

Ho separato il metodo GetWeeks in due metodi, uno dei quali è un metodo privato per rendere il mio codice più pulito e più comprensibile. Ora, quando vedo questo metodo privato, penso che sto violando SRP?

La mia domanda è: dovrei separare queste funzioni nella loro classe come WeeksWithDaysCreator o anche WeeksCreator chiamando DaysCreator ? O dovrei lasciare questo nella Service Class?

Modifica: voglio sapere quanto codice dovrei inserire nel mio livello di servizio e quando dovrei separare il codice nella sua classe.

c# clean-code solid single-responsibility

posta Sandman 24.10.2017 - 09:41

fonte

1 risposta

Leggi altre domande sui tag c# clean-code solid single-responsibility

Progettazione del sistema per un problema del server client Rileva quando un file viene creato (su un server web) e pronto per l'uso in una delle tante directory

score 2 · Accepted Answer

Dovresti estrarre il codice nella sua classe se è concepibile che sarebbe chiamato da un codice diverso dal chiamante corrente, in particolare dal codice che non fa essenzialmente la stessa cosa.

Un esempio perfetto di codice che dovrebbe essere indipendente sarebbe il codice che costruisce semplicemente i giorni della settimana. Molti chiamanti immaginabili potrebbero usarlo, quindi è una buona idea calcolarlo anche se in realtà c'è solo un chiamante e questo probabilmente non cambierà . Il motivo è semplicemente che è più facile pensare a un solo compito alla volta: il calcolo della data o la logica di parcheggio.

Se il tuo codice non modifica la logica di business e di parcheggio, è meno chiaro che si tratta di funzionalità che potrebbero essere utilizzate in modo diverso. Sai meglio di noi se questo è il caso, ma potrebbe essere.

Un controesempio è una routine che esegue calcoli complicati su un elemento pubblicitario in un flusso di lavoro complicato (ad esempio dichiarando le tasse, verificando il codice dello space shuttle). Un tale codice per scopi speciali è quasi certamente inutile al di fuori del contesto in cui si trova ora. Tale codice dovrebbe certamente andare nel suo stesso metodo, ma una classe separata è spesso eccessiva.