[OT] Tool per estrarre membri pubblici delle classi

[dott104]

Salve a tutti,
devo estrarre tutte le inferfacce pubbliche di una classe, tipo come fa javadoc.

Visto che la classe non ha il minimo commento javadoc, sapete se esiste un tool apposito che mi crea un file (txt???) con tutte le signature dei metodi?

Forse javadoc lo può già fare ma serve qualche parametro?

Grazie a tutti

[dott104]

Per ora ho usato JavaDoc, però ho visto che crea una marea di file...
La richiesta di un tool ( o opzioni ) più lite è sempre aperta!

Grazie a tutti

[valia]

Originariamente inviato da dott104
Salve a tutti,
devo estrarre tutte le inferfacce pubbliche di una classe, tipo come fa javadoc.

Visto che la classe non ha il minimo commento javadoc, sapete se esiste un tool apposito che mi crea un file (txt???) con tutte le signature dei metodi?

Forse javadoc lo può già fare ma serve qualche parametro?

Grazie a tutti

che vuole dire le interfacce pubbliche??

[alka]

Originariamente inviato da valia
che vuole dire le interfacce pubbliche??

Penso che intenda "tutto ciò che è public".

[valia]

e ci sono pure io, ma visto che in java "interfaccia" è una cosa che ha un determinato significato, la domanda mi sorge spontanea

[dott104]

Scusate se ho usato il termine "intefaccia" in modo errato, ma ho usato quello giusto nel titolo "signature/firme".

In pratica mi capita spesso di scrivere interfacce molto complesse e in alcune fasi del progetti è utile dare a chi lavora con me almeno le signature pubbliche in modo che si possano portare avanti con il lavoro costruendo dei mok. Ecco tutto!

Es. di cosa mi servirebbe

class Foo
getGoo();
setGoo(Goo goo);
...
deleteAllGoo();

In questo modo anche non condividendo i progetti si può iniziare a lavorarci!

[valia]

se il problema è condividere il codice con un team di sviluppo ti consiglio di passare a sistemi di condivisione come svn e cvs, è la soluzione più semplice, diretta, efficace

[alka]

Originariamente inviato da valia
se il problema è condividere il codice con un team di sviluppo ti consiglio di passare a sistemi di condivisione come svn e cvs, è la soluzione più semplice, diretta, efficace

Credo che l'esigenza dell'utente sia più di documentazione che non di condivisione del codice. In pratica, penso che - oltre a condividere il codice - voglia anche creare una sorta di schema di come questo è fatto a livello di architettura.

[valia]

beh lo schema allora credo sia meglio crearlo a monte (magari con UML) e non a valle dopo aver scritto il codice, non trovi?
Anche perché se come dice lui, tutti possono lavorarci senza avere lo stesso progetto, quando devono unirlo che succede? Lo scambio di queste info penso sia diretto all'unione, quindi usa quello che hai (javadoc + progettazione a monte condivisa) e non partendo dal fondo (che poi ognuno avrà fatto una roba ed è un casotto unire tutto)

[alka]

Originariamente inviato da valia
beh lo schema allora credo sia meglio crearlo a monte (magari con UML) e non a valle dopo aver scritto il codice, non trovi?

Secondo me, stiamo parlando di esigenze diverse.

Comunque sia, UML puoi utilizzarlo sia prima che dopo la codifica (non è obbligatorio utilizzarlo solo a monte), ma la sua utilità risiede specificatamente nell'esigenza di documentare un sistema, un'architettura. Probabilmente, l'autore della discussione non vuole una cosa così complicata, ma semplicemente ottenere una documentazione piana delle classi che ha creato e dei membri di queste classi che è possibile utilizzare, una sorta di "reference", che è diverso da una documentazione realizzata con standard UML, che invece descrive il sistema sotto diversi aspetti e sfaccettature.

Originariamente inviato da valia
Anche perché se come dice lui, tutti possono lavorarci senza avere lo stesso progetto, quando devono unirlo che succede?

Se la "documentazione" (intesa nel senso più ampio possibile) viene generata da un tool, come spesso accade, verrà aggiornata - anche automaticamente - al momento dell'unione delle modifiche.

E' possibile configurare parecchi sistemi CVS per fare questo (infatti, non volevo dire che il suggerimento di utilizzare un CVS fosse sbagliato, anzi penso che al giorno d'oggi sia quasi imprescindibile, addirittura anche per uno sviluppatore singolo).

Originariamente inviato da valia
Lo scambio di queste info penso sia diretto all'unione, quindi usa quello che hai (javadoc + progettazione a monte condivisa) e non partendo dal fondo (che poi ognuno avrà fatto una roba ed è un casotto unire tutto)

Questa penso sia una questione che esula dal problema principale: qui si tratta solo di comunicare.

Ciao!