Progetto opensource JGush

[andremar]

Mi hai chiesto... Ma se rispondi con queste giustificazioni dubito che imparerai molto...

>In realtà la classe va estesa per implementare i metodi da far eseguire ai widget ecco perche ho dato questo nome...

Vuoi dire che non ti sembra un brutto nome e che sei fiero di un WidgetMethod con execMethod, qualunque cosa signfichi? Una classe che dice che un "coso" "esegue" qualcosa? Contento te... soprattutto se vuoi che altri COLLABORINIO e GUARDINO IL TUO CODICE


>Questo dato è richiesto da freemarker perchè verifica la versione installata nel progetto...
E tenere numeri cablati nel codice non ti fa suonare un piccolo campanello di allarme?
Mai sentito parlare di mantenibilita'?


>Ho deciso di non utilizzare Maven, è un errore? (credo sia solamente una semplificazione utilizzarlo)
Gia, molto meglio schiagffare i binari jar direttamnete nel sorgente (e sshh non lo dire a quelli di GitHub che se se ne accorgoo ti cancellano il progetto - visto che e' vietato mettere i jar li dentro). E costringere i tuoi "collaboratori" a usare eclipse (o quello o ciccia).
Puoi usare ant-ivy, puoi usare gradle, sbt, buildr. NON puoi non mettere una build perche senza la build il tuo progetto non si puo' nemmeno compilare senza stare ad armeggiare con le configurazioni varie.


>I progetti in realtà sono più di tre e questo per far in modo da importare solamente il codice che interessa ad esempio se si volesse utilizzare solamente il CMS e non il modulo DB non importa JGush_db, se fosse stato tutto unito non si avrebbe avuta questa possibilità.

Ah certo... per queste cose, non si fanno 3 progetti, si fanno 3 sottoprogetti, si che creano tre jar e lasciavi importare agli utenti la dipendenza. Questi e' il modo corretto. Ancora, vuoi collaboratori ? come minimo devi seguire le best practices, e non inventarti le tue.



>In realtà è più comodo utilizzare le eccezioni, ho agito cosi perché mi sono preoccupato delle performance...
Scusa ridicola.
Mi stai dicendo che in un metodo build_config eseguito una volta sola sono importanti LE PERFORMANCES?
E anche se fosse importante quel micromillesimo di secondo, usando una eccezione ti risparmi la if(build_config() == -1)quindi il risoultat e' (infinitesimamente) piu efficiente. E' solo una brutta routine copiata da un programma c, si vede lontano di un miglio.



>Qui in realtà ti sbagli... so bene la differenza tra "".equals( method ) e method.equals( "" ) infatti se guardassi bene quel costrutto IF noteresti che non cerco di prevenire un NullPointerException.

Mmm qui hai ragione. Stai controllando de method e' null o stringa vuota. if(method==null && "".equals(method)) e' equivalemnte a if("".equals(method)) ma li ci sta un ||. Come non detto mi sono sbagliato io.

[Rikim]

- questa e' carina: if( null==method || "".equals( method ) )
Ora, gli esperti usa di solito "".equals(method) invece di method.equals("") per eveitare il null pointer quando method e' null. Qui tu usi la tecnica degli esperti ma si vede che no la hai capita perche hai messo anche il controllo (del tutto inutile) null==method.

con

if(null==method || "".equals(method))

si può generare un eccezione per essere sicuri che la stringa method sia valida (ad esempio in un metodo) e scrivere "".equals(method) o method.equals("") in questo caso è indifferente!

esempio:

public void pippo(String method){
     if(null==method || "".equals(method))
           throw new RuntimeException("method == null or is \"\"");
     
     //. . .
}

[cataDesign]

Grazie per gli ottimi consigli sicuramente mi aiuteranno a scrivere del codice di miglior qualità.