un sacco di piccoli oggetti - OO pasta [chiuso]

1

Nel codice su cui sto lavorando, ci sono molti piccoli oggetti come:

    class HasFieldLameSetter
    {
     public:
        HasFieldLameSetter(field& p_):m(_p){}
        void set(bool p2)
        {
            m.hasLame = p2;
        }   
       field& m; 
   };

Avere un sacco di classi piccole crea una "pasta di codice" difficile da leggere e complicata. A volte, leggerlo è davvero molto difficile perché trascorro molto tempo saltando da un file all'altro per scoprire che la classe ha fatto qualcosa di banale come nell'esempio di impostazione bool su true. Inoltre, questi oggetti vengono passati ovunque in giro per "dipendenza da iniezione" che rende ancora più difficile la lettura.

Come faccio a convincere l'autore del codice a scrivere oggetti leggermente più grandi?

Secondo me troppi piccoli oggetti sono solo un incubo per i programmatori. Mi sto perdendo qualcosa o c'è un errore nel mio modo di pensare? Sarei felice di leggere tutti i documenti che potrebbero cambiare il mio punto di vista.

    
posta CyberGuy 10.09.2013 - 19:27
fonte

1 risposta

4

Potrei essere d'accordo? Non spesso.

È universalmente esclusa la best practice che un oggetto abbia una e una sola responsabilità di cambiare (Principio di Responsabilità Unica). Per qualcosa di simile, il codice molto probabilmente ha bisogno di essere molto granulare per comporre questi piccoli oggetti teeny in cose più significative.

È anche molto comune nei vecchi C ++ e Java, dove gli oggetti minuscoli sono essenzialmente funtori / delegati / oggetti funzione, ma il linguaggio non supporta una sintassi piacevole per ridurre questo tipo di piastra.

Un mucchio di minuscoli oggetti può essere sovrastimato o "troppo" astratto, ma non è un incubo e occasionalmente necessario. Preferirei avere oggetti troppo piccoli o troppo grandi ogni giorno.

    
risposta data 10.09.2013 - 21:37
fonte

Leggi altre domande sui tag