# Warum kann Math nicht instanziert werden?



## ErnstC (1. Feb 2008)

Hallo allerseits,
In der Klasse Math wird kein Konstruktor implementiert (habe ich der Doku entnommen, dort finde ich keinen).
Also muss doch der Standardkonstruktor intern (mit dem Modifizierer public) erzeugt werden.
Warum kann dann Math nicht instanziert werden?
Math m = new Math();  // gibt Fehlermeldung des Compilers

mfg
Ernst


----------



## Kim Stebel (1. Feb 2008)

Mal abgesehen davon, dass es absolut sinnlos ist, Math instanziieren zu wollen, steht in Math wahrscheinlich so etwas:
private Math(){}

Und da private Methoden nicht in der Dokumentation auftauchen...


----------



## Beni (1. Feb 2008)

Math hat einen Konstruktor, nur ist der private...

Was willst du überhaupt mit einem Math-Objekt?


----------



## Guest (1. Feb 2008)

Beni hat gesagt.:
			
		

> Math hat einen Konstruktor, nur ist der private...
> 
> Was willst du überhaupt mit einem Math-Objekt?


------------------------------------------------

1) Ich will mit Math ein bisschen testen.

2) Warum wird der private-Konstruktor nicht in der Java-Doku erwähnt??

mfg
ErnstC


----------



## SlaterB (1. Feb 2008)

> Ich will mit Math ein bisschen testen.

was bringt es dir, mit einem total leeren Objekt zu testen?
die statischen Operationen musst du eh an der Klasse aufrufen, nicht am Objekt

> Warum wird der private-Konstruktor nicht in der Java-Doku erwähnt??

wie man's sieht, wenn gar nix über Konstruktoren in der API steht,
dann bedeutet es ja offensichtlich, dass kein öffentlicher Konstruktor da ist -> nur private 

(vielleicht auch noch protected usw, bin mir jetzt nicht sicher, aber keine Info ist durchaus auch ne Info)


----------



## Ariol (1. Feb 2008)

Statt

```
Math math = new Math();
double d = math.round(3.1111111);
```
schreibt man

```
double d = Math.round(3.1111111);
```


----------



## Guest (1. Feb 2008)

Um hier noch weitere Fragen zu vermeiden:

Wenn man mit Math arbeiten / testen will benötigt man KEIN Objekt der Klasse sondern arbeitet mit den STATISCHEN Methoden die an der Klasse aufgerufen werden und nicht an einem Objekt.


----------



## outbreaker (1. Feb 2008)

> > Warum wird der private-Konstruktor nicht in der Java-Doku erwähnt??



Da du diesen Konstruktor eh nicht aufrufen kannst also wozu soll er dann in die Doku?


----------



## maki (1. Feb 2008)

Du brauchts kein Objekt der Klasse Math, da es sich nur um statische Methoden handelt, eine Utitlity Klasse eben. 
Objekte davon machen keinen Sinn, deswegen wurde es "verboten", daher der private Konstruktor.


----------



## Guest (1. Feb 2008)

maki hat gesagt.:
			
		

> Du brauchts kein Objekt der Klasse Math, da es sich nur um statische Methoden handelt, eine Utitlity Klasse eben.
> Objekte davon machen keinen Sinn, deswegen wurde es "verboten", daher der private Konstruktor.


--------------------------------------------------------------------
Dadurch, dass der Standard-Konstruktor als private deklariert wurde, kann man keine Objekte dieser Klasse erzeugen.
Frage:
Warum wurde Math dann nicht als abstract Klasse deklariert?
Dadurch erreicht man auch, dass kein Objekt von Math erzeugt werden kann.


mfg
ErnstC


----------



## Niki (1. Feb 2008)

Nein, das würde genau das Gegenteil bewirken, weil du von Math erst ableiten müsstest und erst recht wieder ein Objekt erzeugen musst von der Subklasse.
abstract sagt nur aus, dass du von dieser Klasse erst einen konkreten Subtype brauchst. Dieser Subtype muss alle abstrakten Methoden überschreiben (außer er ist eben nicht konkret, also wieder abstrakt)


----------



## tfa (1. Feb 2008)

Anonymous hat gesagt.:
			
		

> Frage:
> Warum wurde Math dann nicht als abstract Klasse deklariert?
> Dadurch erreicht man auch, dass kein Objekt von Math erzeugt werden kann.



Wenn sie abstrakt wäre, könnte man eine Subklasse davon ableiten. So könnte man doch
Objekte vom Typ "Math" erzeugen, was sinnlos ist.


----------



## Murray (2. Feb 2008)

tfa hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...



Von einer abstrakten Klassen kann man nur dann erfolgreich (also ohne Compile-Fehler) eine anderen Klasse ableiten, wenn die abstrakte Klasse mindestens einen nicht als "private" deklarierten Konstruktor hat. Daher wird es von manchen als sinnlos angesehen, abstrakte Klassen mit lediglich privaten Konstruktoren zu definieren .

Abstrakte Klassen sind solche, die zwar grundsätzlich instanziierbar sind, aber eben nur in Form einer Ableitung. Möchte man sicherstellen, dass eine Klasse niemals instanziiert werden kann, dann ist das Schlüsselwort "abstract" nicht das Mitttel der Wahl; wenn man stattdessen alle Konstruktoren als "private" deklariert, dann verhindert man das zuverlässig.


----------



## Guest (2. Feb 2008)

Murray hat gesagt.:
			
		

> tfa hat gesagt.:
> 
> 
> 
> ...


------------------------------------------------------
Könnte man nicht auch folgendes machen, um zu verhindern, dass von einer Klasse kein Objekt erzeugt werden kann:
Die Klasse abstract _und_ final machen.
Mit abstract kann von der Klasse kein Objekt erzeugt werden.
Mit final kann von einer Unterklasse dieser Klasse kein Objekt erzeugt werden (weil man keine Unterklasse bilden kann).

mfg
ErnstC


----------



## SlaterB (2. Feb 2008)

echt toll, das Posting direkt davor komplett zu zitieren, welches selber schon den gleichen Quatsch gemacht hat,

abstract und final zusammen ist zufälligerweise gerade in Java verboten


----------



## maki (2. Feb 2008)

abstract heisst, man sollte von dieser Klasse erben.
final heisst, man darf von dieser Klasse nicht erben.

Deswegen sind die beiden Schlüsselwörter im Verbund nicht zugelassen.


----------



## Quaxli (2. Feb 2008)

Abstract bedeutet eigentlich, daß man diese Klasse nicht instanziieren kann und daher erben MUSS 
Dabei ist man meistens gezwungen vorhandene abstrakte Methodenrümpfe mit Leben zu füllen.


----------



## maki (2. Feb 2008)

Quaxli hat gesagt.:
			
		

> Abstract bedeutet eigentlich, daß man diese Klasse nicht instanziieren kann und daher erben MUSS
> Dabei ist man meistens gezwungen vorhandene abstrakte Methodenrümpfe mit Leben zu füllen.


Naja, statische Methoden können schon aufgerufen werden, diese werden aber bekanntlich  nicht vererbt


----------

