Quello che spero di averti fatto capire della programmazione a oggetti e' che e' un modo completamento diverso (e migliore) di ragionare.

Non devi piu' ragionare nei termini di "cosa devo fare" (ovvero di program flow da inizio a fine), ma prima di "quali entita' devo rappresentare". Quindi non devi piu' sederti alla scrivania e iniziare a rappresentare cosa vuoi fare, ma devi iniziare a creare una astrazione, una rappresentazione, di un insieme di entita' del mondo reale che interagiscono fra loro in modi predefiniti.

Una connessione e' un ottimo esempio di classe di oggetti, in quanto ha uno stato (connesso, disconnesso, targetHost, targetPort, currentUser, currentPassword), e una serie di comportamenti che puo' effettuare (executeQuery, executeUpdate, executeDelete, flush(), close(), etc).

Cio' che invece e' un pessimo esempio di classe sono le funzioni matematiche. Che senso ha una classe per la funzioen seno, o coseno? Che senso ha dire che esiste un oggetto "seno"? Non esiste, in quanto non ha uno stato, ne' ha comportamenti. E' solo una funzione matematica che dato un valore di ingresso ne restituscie uno in uscita. Questo e' il classico candidato per un metodo statico. In caso non sapessi, un metodo statico e' un metodo che si puo' invocare su una classe e non su una sua istanza. Tipicamente, tante operazioni 'statiche' vengono agglomerate in classi dette "utility class" che sono un agglomerato di metodi statici che fanno cose non mettibili altrove.

Ad esempio, un classico e' la classe Math di Java che contiene una lunga serie di metodi statici, come ad esempio Math.sin(), Math.cos(), Math.abs() e cosi' via.

La cosa piu' importante, comunque, e' che se intendi programmare a oggetti (e te lo consiglio, e' una via senza ritorno) devi iniziare a pensare a modellare e astrarre gli OGGETTI (inteso in senso concreto, non in senso informatico) che vuoi rappresentare, e non la sequenza di operazioni.