<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-05-09 18:45 GMT+01:00 Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1za" class="a3s" style="overflow:hidden">Sono certo che molti criticheranno il fatto di partire subito definendo una classe<br>
ma per mia esperienza, con questo tipo di approccio un programma iniziato<br>
per piccole esigenze può crescere bene. Se si buttano giù linee di codice<br>
affastellate, alla fine tocca buttare tutto e ripartire :D.</div></blockquote></div><br>Io criticherei il fatto che una classe siffatta e' inusabile e viola in modo necessario piu' o meno ogni regola di programmazione ad oggetti.</div><div class="gmail_extra">Il problema piu' grosso e' che mischia concerns molto diversi: input, output e logica business. Non solo: lega l'input ad una specifica logica di input.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Allora, andiamo per gradi: tipicamente vuoi che una classe abbia delle invarianti. Quanto piu' costante e' la classe, quanto piu' e' facile mantenere delle invarianti. L'ideale e' avere una classe completamente immutabile: le invarianti vanno controllate nel costruttore e poi non sono piu' un problema; inoltre hai garanzie forti sul fatto che qualunque triangolo hai nel tuo programma rispettera' *sempre* le invarianti (altrimenti il costruttore avrebbe lanciato un'eccezione).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Viceversa, con un approccio a mutatori ti trovi a doverle controllare ogni volta che cambi qualcosa (e potenzialmente a dovere introdurre il concetto di transazione se hai mai due mutatori che vanno chiamati insieme per mantenere l'invariante. E non e' codice esattamente banale da scrivere correttamente (immagina proprio un triangolo: immaginatelo mantenuto con dei vertici, puoi trovarti che modificando un vertice non hai piu' un triangolo e devi appunto spostare *due* vertici). </div><div class="gmail_extra"><br></div><div class="gmail_extra">Riguardo l'input, hai legato:</div><div class="gmail_extra">1. la fonte di input</div><div class="gmail_extra">2. la strategia di input</div><div class="gmail_extra">3. il formato di input</div><div class="gmail_extra"><br></div><div class="gmail_extra">Non solo quella classe funziona esclusivamente prendendo i dati da standard input (per come hai definito l'interfaccia), ma presuppone che quello che hai su standard input sia in uno specifico formato *non* negoziabile. Devi fare *due* letture (e se ti scordi di farne una, hai rotto verosimilmente tutto). </div><div class="gmail_extra"><br></div><div class="gmail_extra">Quindi la classe non e' adattabile ne a cose come prendiamo input da file, ne a cose come invece che prendere i numeri separati da newline li prendiamo separati da tab nella stessa linea. Per piu' forte ragione, anche cose tipo prendiamo i triangoli da un database non si possono fare e nemmeno cose come prendiamo i triangoli da un file json (o da un pickle o da dove ti pare).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Non solo: anche cose a livello di logica di input piu' di alto livello sono rotte (per esempio invece che prendere base e altezza -- assumendo che la base sia un segmento, quindi vuole dire succhiare due punti oppure un punto, una direzione e una lunghezza -- vuoi prendere invece 3 vertici -- che potrebbero essere in coordinate cartesiani o polari).</div><div class="gmail_extra"> </div><div class="gmail_extra">L'output ha essenzialmente lo stesso problema (sebbene almeno non abbia necessita' di due chiamate). </div><div class="gmail_extra"><br>Quindi in altre parole il principiante che si trovasse avendo scritto una classe del genere non sarebbe nella condizione di potere estendere il suo codice facilmente per fare cose estremamente banali e legittime. Lo schema e' talmente lontano da una buona struttura che l'unica cosa che potrebbe fare sarebbe aggiungere qualche dozzina di metodi ad hoc -- che poi non sarebbe testare in modo incrociato e si troverebbe con una API fragilissima --. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Personalmente, rimanendo all'esempio del triangolo, progetterei tutto con una named-tuple (ma questo e' un dettaglio implementativo) che tiene un certo set di dati minimi in memoria. Poi ci sabbero dei metodi statici per prendere diverse strutture (che so... base - altezza, 3 vertici, etc etc etc). Ovviamente tutto questo richiede di un concetto di Punto relativamente ben fatto (ancora una volta immutabile, che puoi costruire, per dire, con coordinate cartesiane oppure polari). A questo punto il triangolo avrebbe un metodo per darti l'area. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Il resto rimane molto piu' semplice.<br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>