Chaining Programming

Chaining programming, is it a damn practice or a good thing ?

ADVANTAGES

1. L'utilizzo è opzionale e quindi soggettivo, sicuramente può essere più elegante quando ci sono funzioni con molti parametri
2. The point is - in 99% cases you can probably do just as well or even better without method chaining. But there is the 1% where this is the best approach.
3. il Chaining è un modo per scrivere codice elegante/veloce (smart)
4. "Fluent" è un concetto ampio che ha a che fare la leggibilità del codice ed ilChaining è solo un metodo per raggiungere tale obiettivo.
5. Il Chaining è una tecnica per costruire una feature mancante
6. E' un grande idioma, ma spesso se ne abusa
7. Non serve più usare variabili intermedie dove salvare ogni passo del processo, però la cosa non aiuta nella fase di debugging.
8. Our code is more maintainable because we have simple, magro, specialized methods
9. Qualcuno preferisce quei metodi di chaining che agiscono solo sull'oggetto originale, settaondo più proprietà o lanciando metodi di utilità varie, esempio:
   1. foo.setHeight(100).setWidth(50).setColor('#ffffff');
   2. foo.moveTo(100,100).highlight();
10. Se si evitano le cose brutte del chaining allora si possono avere dei benefici:
    1. Non effettuare il chaining tra diverse classi di oggetti
    2. Creare delle routine spe ifiche per il chaining
    3. In una routine di chaining fai solo una specifica cosa
    4. Usalo quando aumenta la leggibilità
    5. Usalo quando rende il codice più semplice

 

DISVANTAGES

1. Il debug è difficile, non puoi mettere i breakpoint in un punto preciso. Se non si usa il chaining il debugging è più flessibile e puoi controllare più cose. Se un metodo genera un eccezione, il browser fornisce la riga, ma non sai quale metodo sia stato BE QUESTO NON E' PROPRIO VERO PERCHE' IN JS SI POSSONO MANDARE I METODI A CAPO, TANTO POI ALLA FINE COSI' E' PURE PIU' LEGGIBILE.
2. E' meglio avere più righe di codice corte e concise, ed in una riga ci va un solo metodo. E' preferibile avere "più righe" a "lunghe righe".
3. Il fatto di fare chiamate separate ed avere le var intermedie ti danno molte informazioni in più per investigare eventuali bug.
4. Il modello chain è un hack (anche come violazione del buon senso) è per la manutenzione del codice è una cosa pessima.
5. Quando nella catena vengono ritornati anche altri oggetti allora non mi piace più. Certo, logicamente parlando, si può fare tutto il chaining che si vuole, basta fornire le giute API per gli oggetti su cui si sta lavorando. Però cambiare oggetti lungo la catena per me è decisamente un fattore di confusione piuttosto che di leggibilità, perciò un chaining esagerato peggiora le cose. Se poi le API tra i vari oggetti sono simili allora genera confusione.
6. In my opinion, method chaining is a bit of a novelty. Sure, it looks cool but i don't see any real advantages in it.
7. Un Chaining lungo è più fragile, infatti basta solo un piccolo cambiamento di var o function che va tutto in errore
8. Repeating a variable name in the source code has nothing to do with the DRY principle. DRY states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system", or in other terms, avoid the repetition of knowledge (not the repetition of text).
9. Per creare l'API per il Chaining, invece di usare il this qualcuno suggerisce di ritornare una nuova istanza, anche se ci sono degli overhead rispetto a tornare il this

 

 

Note

• Source