Perdonate la domanda banale...

[zipgenius]

Da perfetto novellino, non ho capito come posso creare una classe con una serie di funzioni che poi utilizzerò più volte in varie parti del mio programma. Tutto ciò al fine di non riscrivere doppioni di codice.
Una mano, per favore?
 

[Qlimax]

Codice (Java): [Seleziona]

class MiaMate{

static int sommaInt(int a,int b){
return a+b;
}

}

poi la chiami dove vuoi con

Codice (Java): [Seleziona]

int risultato=MiaMate.sommaInt(1,1);

Diciamo che non è molto OOP.... però...

[vincenzodicicco]

Esisto libri creati proprio per migrare da programmazione procedurale a programmazione object oriented, e ammetto che ancora non mi è del tutto chiaro la differenza  . A tal proposito ti sarei molto grato se mi commenteresti il motivo per cui utilizzare una classe con una serie di metodi proprio come il tuo esempio, non rispetta le regole del programmare ad oggetti.

[Miciux]

Per il semplice fatto che in OOP ogni classe é la rappresentazione astratta di qualcosa. Vedi ad esempio la classe Service che astrae un generico servizio. Una classe che faccia da collezione a metodi statici é comoda ma non astrae ne rappresenta nulla.

Spero di essere riuscito a spiegarmi.
L'OOP all'inizio non é banale ma col tempo si impara ad apprezzarla.

Sent from my Liquid

[vincenzodicicco]

purtroppo no  spero che con il tempo capirò bene anche io  grazie ad ogni modo per la risposta

[Miciux]

Prova a leggere Thinking in java di Bruce Eckel, é un ottimo libro e lo trovi liberamente scaricabile.

http://www.mindviewinc.com/Books/

Sent from my Liquid

[zipgenius]

Per quanto mi riguarda, l'avere una collezione di pezzi di codice riutilizzabili è il risultato degli anni trascorsi a programmare con Delphi una serie di applicazioni che condividono parecchio di quel codice.
Per fare un esempio, il mio software ZipGenius su Windows crea alcune chiavi di registro in cui salva le impostazioni predefinite post-setup e, successivamente, le impostazioni personalizzate di ciascun utente; i software che lo accompagnano spesso devono poter accedere alle stesse informazioni, anche solo per sapere in quale cartella è installato ZipGenius, pertanto nel codice di questi ho incluso la stessa unit che ho usato anche per il programma principale.
Lo so, non è molto ortodosso e potrebbe apparire un tipo di programmazione un po' rozza e poco elegante, ma la comodità di questo sistema è innegabile: anziché creare una DLL, l'insieme di funzioni viene direttamente integrato nel codice principale del programma che si sta realizzando. In questo modo vengono su applicazioni complete in tempi rapidissimi e avere una grossa porzione del codice già pronta ci permette di concentrarci maggiormente sull'aspetto esteriore del software.

[Vytek]

Salve a tutti,
ed un saluto particolare a ZipGenius autore dell'omonimo software che mi ha cambiato la vita (ed uso da una vita...) e che quindi ringrazio tantissimo! (ZipGenius è per me un software fondamentale, tengo il setup sulla mia pennina da battaglia e lo installo praticamente su ogni mio computer personale
Ho avuto la tua stessa esigenza per il mio Almanac e Agafi mi ha descritto una soluzione semplice ed elegante che puoi trovare qui:

Classe con utility comuni....non funziona - Android Developers Italia

Spero possa essere d'aiuto ....ancora grazie per il tuo mitico ZipGenius...

Un saluto...

[zipgenius]

Salve a tutti,
ed un saluto particolare a ZipGenius autore dell'omonimo software che mi ha cambiato la vita (ed uso da una vita...) e che quindi ringrazio tantissimo! (ZipGenius è per me un software fondamentale, tengo il setup sulla mia pennina da battaglia e lo installo praticamente su ogni mio computer personale

Grazie a te
(OT) ZipGenius è "portable" e può essere usato senza installazione sulla penna USB (basta prelevare l'exe principale e le DLL di contorno - poi ti spiego in privato come fare) (/OT)

[MarcoDuff]

Esisto libri creati proprio per migrare da programmazione procedurale a programmazione object oriented

Bruciali!

Scherzi a parte (anche se non scherzavo ), la soluzione è proprio quella consigliata da Vytek (quindi quella di Agafi), ovvero la creazione di una classe Singleton che si occupa delle Utility comuni. Aggiungo che se queste Utility sono indipendenti dalla singola applicazione (ovvero vengono utilizzate allo stesso modo da più applicazioni), è bene metterle in un progetto java (non android!) a se e linkarlo da tutte le applicazioni android/java che lo usano. In questo modo crei a tutti gli effetti una DLL (o meglio una libreria jar) centralizzata e molto riusabile, quindi non rozza e molto elegante.

Per il semplice fatto che in OOP ogni classe é la rappresentazione astratta di qualcosa. Vedi ad esempio la classe Service che astrae un generico servizio. Una classe che faccia da collezione a metodi statici é comoda ma non astrae ne rappresenta nulla.

Permettimi di storcere un poco il naso!

I metodi statici fanno parte della programmazione ad oggetti. Non sarebbe possibile creare un oggetto Singleton senza un metodo statico.
E non condivido neppure la definizione che in OOP ogni classe é la rappresentazione astratta di qualcosa (tecnicamente tutto quello che scrivi in java è estensione di un oggetto (Object) ma questo non significa che stai programmando in OO). La vera svolta della programmazione OO sta nel fatto che ogni oggetto creato ha una sua responsabilità rendendo il codice estremamente modulare e riusabile.

[vincenzodicicco]

Grazie a tutti per le risposte  ragazzi 

[Miciux]

Permettimi di storcere un poco il naso!

I metodi statici fanno parte della programmazione ad oggetti. Non sarebbe possibile creare un oggetto Singleton senza un metodo statico.
E non condivido neppure la definizione che in OOP ogni classe é la rappresentazione astratta di qualcosa (tecnicamente tutto quello che scrivi in java è estensione di un oggetto (Object) ma questo non significa che stai programmando in OO). La vera svolta della programmazione OO sta nel fatto che ogni oggetto creato ha una sua responsabilità rendendo il codice estremamente modulare e riusabile.

Teniamo conto però che il Singleton è un pattern e i pattern sono nati successivamente alla OOP.
Usare i pattern non è sempre usare OOP, così come utilizzare erroneamete eredità o polimorfismo non è OOP.

Per esempio, se implemento da una classe che si chiama Gelato l'interfaccia Loggable non sto usando OOP, lo faccio per comodità ma mi allontano da quella che sarebbe stata una gerarchia corretta semanticamente oltre che sintatticamente.

Tieni poi conto che Java non è un linguaggio che utilizzi un OOP puro come ad esempio SmallTalk.