Refactorable God v.s. troppi classi [duplicati]

Non ricordo il capitolo, ma l'autore di working with legacy code ma penso che il libro suggerisca il seguente flusso di lavoro:

1. assicurati di avere dei test. Se non riesci a testare il tuo codice senza modificandolo, esegui solo le modifiche di base / semplici necessarie.

2. codifica un test per la nuova funzionalità

3. codifica la funzionalità direttamente dove vuoi che si verifichi il lavoro e fai il test pass

4. refactoring per rimuovere la duplicazione e rendere il codice compatibile con SOLID.

Anche senza test, tendo a seguire uno schema simile: per prima cosa, far funzionare la cosa nel modo più semplice e semplice, quindi immediatamente refactor fino a quando non sei soddisfatto dell'organizzazione del codice. Se aspetti, tu (o il tuo collega) pagherai un prezzo più alto cercando di capire il codice disordinato.

Il fatto che in primo luogo risolvi il problema nel modo più semplice e diretto ti aiuta ad evitare di sovrastimare la soluzione. Concentrarsi innanzitutto sulla correttezza, quindi su leggibilità / architettura ti aiuta davvero ad essere produttivo.

Quando crei un nuovo metodo, per prima cosa pensa:

• Questo metodo corrisponde a una proprietà o a un comportamento di un oggetto o:

• È qualcosa di completamente nuovo?

Nel primo caso, preferirai metterlo nella classe corrispondente. Nel secondo caso, infatti, creerai una nuova classe.

Il problema con il primo caso è che a volte finisci con una classe troppo grande. Questo è un suggerimento per cui la classe dovrebbe essere refactored in più classi più piccole. Ciò che è grande o non dipende dalle circostanze. Ad esempio:

Rectangle
{
    int x;
    int y;
    int width;
    int height;
}

può essere facilmente rifatto in:

Rectangle
{
    Point position;
    Size size;
}

Point
{
    int x;
    int y;
}

Size
{
    int width;
    int height;
}