🚀 go-pugleaf

Generalnie zgodzę się ze wszystkim co napisałeś, poza tymi statycznymi metodami. Taka klasa będzie bezstanowa, możemy ją więc traktować jako singleton (najlepiej w jakimś kontenerze IoC) z instancyjnymi metodami. Wtedy zawsze łatwiej coś takiego podmienić w testach (nie wszystkie stubery sobie radzą ze statycznymi metodami)

W dniu czwartek, 12 grudnia 2013 21:51:11 UTC+1 użytkownik Piotr Rezmer napisał:
> Jadalbert pisze:
> 
> 
> 
> > public abstract class Figura {
> 
> 
> 
> > public class Kolo extends Figura {
> 
> 
> 
> > i teraz:
> 
> > public class Licz {
> 
> > 	private Figura figura;
> 
> > 	private double PoleObwod;
> 
> >
> 
> > 	public Licz() {}
> 
> >
> 
> > 	public Licz(Figura figura) {
> 
> > 		this.figura = figura;
> 
> > 	}
> 
> >
> 
> > 	public double getPoleObwod() {
> 
> > 		return figura.getPole() * figura.getObwod();
> 
> > // i tu oczywi�cie b��d bo obwodu nie ma w klasie Figura !
> 
> 
> 
> Zacz��bym od uporz�dkowania klas. Czyli najwy�sza klasa: Figura, z nie 
> 
> dziedziczy Krzywa, Powierzchnia, Bry�a.
> 
> Krzywa ma w�a�ciwo�� Obw�d
> 
> Powierzchnia ma w�a�ciwo�� Pole
> 
> Bry�a ma w�a�ciwo�� Obj�to��
> 
> 
> 
> Ko�o, Elipsa, Czworok�t,... dziedzicz� z powierzchni
> 
> Okr�g dziedziczy z Krzywej.
> 
> *�cian dziedziczy z Bry�y.
> 
> 
> 
> Klasa Licz nie powinna otrzymywaďż˝ figury przez konstruktor, gdyďż˝ 
> 
> oznacza�oby to �e przy ka�dym liczeniu musisz wo�a� konstruktor a to 
> 
> kosztuje. Klasa Licz powinna byďż˝ klasďż˝ Utility ze statycznymi metodami, np.
> 
> 
> 
> 
> 
> public class Licz {
> 
> 
> 
> static public Double getPole( Powierzchnia powierzchnia ) {
> 
> ...
> 
> 	return pole;
> 
> }
> 
> 
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> pozdrawiam
> 
> Piotr
> 
> XLR250&bmw_f650_dakar