Tecnicamente sì. La forma della stringa risultante non è granché (si può fare meglio) ... è questione di scelte/gusti.Originariamente inviata da megaorso
Se non ci sono di mezzo questioni di a) sincronizzazione/concorrenza, b) logiche particolari che un getter potrebbe applicare, usare un campo o un getter nel toString è abbastanza indifferente, detto in generale. Ripeto, se non ci sono altri aspetti da considerare.
La stringa del toString spesso/tipicamente è una stringa molto "tecnica" e serve per logging/debugging o comunque per utenti "tecnici".
Ma sovente può anche essere mostrata all'utente comune, come nel tuo caso. Quindi la forma dei dati nella stringa dipende appunto da CHI dovrà leggere quella stringa.
Il framework standard per le classi "bean" di dati usa di norma una forma del tipo
nome.qualificato.Classe[prop1=xxx,prop2=yyy, ..... ]
La classe java.awt.Rectangle ad esempio fornisce una stringa
java.awt.Rectangle[x=10,y=10,width=200,height=100]
No, NON è quello il problema. Nella tua classe astratta Poligono "sai" solo area e perimetro perché quelli sono i metodi che tutte le sotto-classi concrete sicuramente dovranno offrire. Ma in Poligono non hai e non sai le informazioni più specifiche relative a ciascuna figura.
Se vuoi generalizzare un po' la forma si può realizzare una piccola architettura di questo tipo: in Poligono metti la implementazione concreta di toString() in cui comporrai la stringa inserendo sicuramente i dati che Poligono "sa". Poi all'interno della composizione userai un metodo es. String infoFigura(). Questo metodo è astratto (e public o anche solo protected) in Poligono e dovrà essere implementato dalle sotto-classi.
Quindi ciascuna sotto-classe non dovrà più ripetere l'intero toString() ma solo fornire le informazioni specifiche alla sua figura (es. i due lati di un rettangolo o il raggio di un cerchio).
Rispondi quotando
