Comparare due stringhe di istanze diverse

[Sevenis]

In ogni caso non hai bisogno di quel metodo sonoUguali, per testare l'uguaglianza di due stringhe ti basta fare stringa1.equals(stringa2). Ovviamente puoi scambiare l'ordine delle stringhe e fare anche il contrario a meno che la prima stringa non sia NULL, nel qual caso l'istruzione lancierà una NullPointerException, perché non puoi invocare un metodo su un oggetto NULL (vale ovviamente in entrambi i casi, è solo per dire che le due scritture non sono sempre equivalenti, perché se è la seconda stringa a essere null il metodo non causa errori, anche se magari sarebbe meglio lo facesse ...).

Ma è quello che ho fatto all'interno del metodo solo che s1 e s2 sono due entità di due istanze diverse...

Piccola curiosità: che senso ha chiamare la tua classe IndirizzoPersona, se modella il contatto di una rubrica? Non è meglio avere una classe Contatto ? La classe potrebbe anche prevedere uno o più costruttori, in modo da evitare di richiamare tutti i set al momento della creazione, e sarebbe comodo avere anche un metodo toString(), visto che cerchi di stampare a video tutti i campi. Quest' ultimo dettaglio puoi rimandarlo a più avanti se non l'hai ancora visto chiaramente, ma male non fa guardarsi subito come funziona

hai ragione... l'ho chiamata così solo perché me lo richiedeva l'esercizio ma indubbiamente Contatto è il nome migliore. In che senso più costruttori per evitare di richiamare tutti i set? toString() ancora non l'ho studiato ma mo ci do uno sguardo

[andbin]

In che senso più costruttori per evitare di richiamare tutti i set?

Es. Un costruttore per impostare nome+cognome, un altro costruttore per impostare nome+cognome+email, un altro ancora che riceve e imposta nome+cognome+email+telefono.
Avere più costruttori in cui ognuno aumenta di un (tipicamente) parametro si definiscono informalmente costruttori "telescopici". Se sono pochi è un conto ma generalmente è bene non abusarne.

[Ansharja]

Ma è quello che ho fatto all'interno del metodo solo che s1 e s2 sono due entità di due istanze diverse...

Sì ma il passaggio attraverso il metodo è superfluo, a meno che tu non voglia fare qualcosa in più oltre al semplice confronto e voglia richiamare più volte il metodo.
Il fatto che s1 e s2 siano campi di due istanze diverse non vuol dire nulla! Se hai le istanze sotto mano puoi confrontarle in qualsiasi punto, puoi benissimo fare ad esempio :

if(marioRossi.getNome().equals(rossimario.getNome())) {
  // fai quello che devi fare ...
}

Se il problema è un altro specifica meglio ma ripeto, una volta che hai le stringhe da confrontare non ha alcuna importanza il fatto che siano di un'istanza o un'altra, create localmente al metodo, variabili statiche o altro.

In ogni caso se l'idea era di scrivere un metodo per determinare quando due contatti siano uguali, il metodo migliore sarebbe ridefinire equals all'interno di IndirizzoPersona, datti un'occhiata anche a questo se la cosa ti interessa

In che senso più costruttori per evitare di richiamare tutti i set?

Al momento stai utilizzando un costruttore vuoto (quello definito implicitamente) per creare un contatto, e poi stai settando manualmente ogni campo. Questa parte sarebbe molto più veloce se prevedessi un costruttore con 4 argomenti in cui setti all'interno i campi, potendo creare un contatto in questo modo :

new IndirizzoPersona ("Mario", "Rossi", "email", 12345);

Il fatto che i costruttori siano uno o più cambia poco, se vuoi poter creare un contatto con meno informazioni può essere utile, per i parametri mancanti puoi settare un valore di default (in questo caso non ha molto senso), o semplicemente lasciarli vuoti.

[Sevenis]

Comunque avevo impostato il set manuale di ogni campo per prevedere un eventuale richiesta di inserimento/modifica all'utente tramite System.out.println()