Datentypen Welcher ist der beste Datentyp?

[DerSpezialist]

In den meisten Tutorials wird Anfängern zu einem String oder einem Int geraten. Ist das nicht schlecht? Int stellt zum Beispiel weniger Speicherplatz zur Verfügung als andere Datentypen. Sollte man nicht lieber die größten Datentypen nehmen, wie zum Beispiel unsigned long long? Da hat man viel mehr Zahlen zur Verfügung, also mehr Freiheiten und es wird unwahrscheinlicher, dass man an Grenzen stößt und das Programm abstürzt.
Aber wenn ich ihn benutze wird mir immer gesagt, es sei "schlechter Programmierstil". Warum wird es als gut angesehen, sich selbst einzuschränken?

 

[InfectedBytes]

Erstmal: In Java gibt es keinen unsigned long long oder ähnliches.

Ansonsten:
Es kommt halt auf das Problem an. Wenn ich nur die Zahlen 1 bis 10 darstellen will, ist es sehr sinnlos nen long zu nehmen.
Wenn ich mit Zahlen rechnen will, ist es halt sehr sinnlos nen String zu nehmen.
Ansonsten ist es halt auch ne Frage des Speichers. Wenn man beispielsweise eine Million Zahlen aus dem Bereich 0-100 speichern will, wäre es nunmal sehr dumm dafür nen long Array zunehmen, obwohl ein byte Array reicht. Warum sollte man auch unnötig speicher verschwenden

 

[neoexpert]

Je simpler der Datentyp desto schneller (in der Regel) wird man damit rechnen können. BigDecimal-Addition ist langsamer als long-Addition ist langsamer als Integer-Additon.

 

[Mxxxt]

Im Prinzip hast dir die Frage selber beantwortet. ->Es reserviert weniger Speicher.
Wozu denn gleich einen größeren nehmen? Du kannst sie beliebig umwandeln, sobald es nötig wird.

 

[Flown]

long-Addition ist langsamer als Integer-Additon

Ahh kommt auf die Prozessor-Architektur und JVM an.

 

[DerSpezialist]

Im Prinzip hast dir die Frage selber beantwortet. ->Es reserviert weniger Speicher.

Aber ist das der einzige Grund warum es schlecht ist? Die meisten Computer haben ja heutzutage sehr viel Speicher. Meiner hat zum Beispiel 1TB und ich habe auch einige Programme, die mehrere Gigabyte groß sind.

 

[Mxxxt]

Wird im Arbeitsspeicher reserviert.

 

[InfectedBytes]

Aber ist das der einzige Grund warum es schlecht ist? Die meisten Computer haben ja heutzutage sehr viel Speicher. Meiner hat zum Beispiel 1TB und ich habe auch einige Programme, die mehrere Gigabyte groß sind.

Es geht hier nicht um die Festplatte, sondern mehr um den RAM

 

[DerSpezialist]

Achso, danke für die Erklärung. Das heißt, als Programmierer muss man quasi abschätzen, was einem wichtiger ist:

Entweder wenig Speicherverbrauch aber mehr Einschränkungen
Oder mehr Freiheit aber dafür ein vollerer Speicher (was ja bei 8-16 Gigabytes nicht so schlimm ist..?)

Mir ist nur schleierhaft, warum man es sich manchmal unnötig kompliziert macht, zum Beispiel auch dass Attribute private sein sollen oder dass man globale Variblen nicht benutzen soll...

 

[Xyz1]

Gute Tuts empfehlen Anfängern kleinere Datentypen als int. (Int gibt's nicht BTW) Also diese Aussage wäre auch falsch.
long braucht auf einmal doppelt so viel Speicher und ist nicht o. B. d. A. langsamer.
Es geht darum, sehr schnell von A nach B zu kommen, sobald aber die Reifen durchdrehen, "bewegst du dich nicht vorwärts".
Diese Metapher erklärt schon alles - ohne ins Detail zu gehen.
Ich wette, da kommen noch lustige Fragen auf uns zu. 😎

 

[InfectedBytes]

Achso, danke für die Erklärung. Das heißt, als Programmierer muss man quasi abschätzen, was einem wichtiger ist:

Entweder wenig Speicherverbrauch aber mehr Einschränkungen
Oder mehr Freiheit aber dafür ein vollerer Speicher (was ja bei 8-16 Gigabytes nicht so schlimm ist..?)

Mir ist nur schleierhaft, warum man es sich manchmal unnötig kompliziert macht, zum Beispiel auch dass Attribute private sein sollen oder dass man globale Variblen nicht benutzen soll...

Am besten fängst du mal ganz von vorn an und liest dir einfach mal ein paar Grundlagen Bücher und ähnliches durch^^.

Was glaubst wieviel du von deinem RAM noch hättest, wenn jedes Programm einfach unnötigerweise 2-8 mal soviel Speicher verbraucht wie nötig?

Ist halt so als würdest du sagen, dass ein Auto beliebig viel Benzin verbrauchen darf, nur weil du nen fetten 100 liter Tank hast.

edit:
und zu dem "unnötig kompliziert":
Findest du es auch unnötig kompliziert das dein Pin Code von der Bank auch "private" ist? Wäre doch viel einfacher und praktischer wenn jeder deinen Pin Code kennen würde!

 

[InfectedBytes]

(Int gibt's nicht BTW)

Wie kommst du denn darauf das es kein int gibt?^^

 

[Xyz1]

Wie kommst du denn darauf das es kein int gibt?^^

Int gibt es nicht, er möge sich mal entscheiden: int oder Integer. Es gibt auch keine rosa Einhörner ...

 

[InfectedBytes]

Int gibt es nicht, er möge sich mal entscheiden: int oder Integer. Es gibt auch keine rosa Einhörner ...

Achso, wegen groß/kleinschreibung^^

 

[DerSpezialist]

Findest du es auch unnötig kompliziert das dein Pin Code von der Bank auch "private" ist? Wäre doch viel einfacher und praktischer wenn jeder deinen Pin Code kennen würde!

Nein, hier macht Geheimhaltung ja Sinn, weil mir sonst jeder mein Geld klauen würde.
Aber warum darf Klasse A nicht auf Attribute von Klasse B zugreifen? Warum der Umweg über Getter und Setter, wenn man auch einfach direkt mit den Variablen arbeiten kann?

 

[Mxxxt]

Achso, danke für die Erklärung. Das heißt, als Programmierer muss man quasi abschätzen, was einem wichtiger ist:

Entweder wenig Speicherverbrauch aber mehr Einschränkungen
Oder mehr Freiheit aber dafür ein vollerer Speicher (was ja bei 8-16 Gigabytes nicht so schlimm ist..?)

Mir ist nur schleierhaft, warum man es sich manchmal unnötig kompliziert macht, zum Beispiel auch dass Attribute private sein sollen oder dass man globale Variblen nicht benutzen soll...

Die Typen belegen halt unterschiedlich viel Platz im RAM.
byte = 8 Bit
short = 16 Bit
int = 32 Bit
long = 64 Bit
char = 16 Bit
float = 32 Bit
double = 64 Bit

private nutzt man um die Variable zu schützen. D.h. sie ist von außen nicht manipulierbar und nur via getter und setter Methoden ansprechbar.

 

[Mxxxt]

Nein, hier macht Geheimhaltung ja Sinn, weil mir sonst jeder mein Geld klauen würde.
Aber warum darf Klasse A nicht auf Attribute von Klasse B zugreifen? Warum der Umweg über Getter und Setter, wenn man auch einfach direkt mit den Variablen arbeiten kann?

Weil sie dann manipulierbar sind von außerhalb deiner App/Applet

 

[Tobse]

Weil sie dann manipulierbar sind von außerhalb deiner App/Applet

Falsch. Manipulierbar sind sie immer (private aber nur mit erheblichem Aufwand).

Es geht bei der ganzen Aktion um das Vorbeugen von Bugs. Man benutzt Setter, damit man die Werte, die einer Variable zugewiesen werden, kontrollieren und limitieren kann. Wenn du denn Füllstand eines Tanks speicherst, macht es wenig sinn, da eine negative Zahl rein zu schreiben. Also schreibt man einen Setter, der diese Überprüfung macht. Damit der Setter nicht aus versehen (absichtlich geht IMMER) umgangen wird, macht man die Variable private. Damit man sie jetzt von aussen aber noch lesen kann, benutzt man einen Getter.
Man benutzt Getter und Setter für alle Variablen, weil man zu Beginn meist nicht alle diese Einschränkungen kennt. Wenn ein Projekt viel Code hat ist es äußerst mühselig alle Zugriffe auf die Variable in Aufrufe des Getters und Setters umzuwandeln.

 

[Xyz1]

Nein, hier macht Geheimhaltung ja Sinn, weil mir sonst jeder mein Geld klauen würde.
Aber warum darf Klasse A nicht auf Attribute von Klasse B zugreifen? Warum der Umweg über Getter und Setter, wenn man auch einfach direkt mit den Variablen arbeiten kann?

Achso, du beziehst dich jetzt hierauf:
http://www.java-forum.org/thema/java-aufgabe.175275/#post-1107609
Die Antwort ist: Ich war bewusst faul, habe im Sinne von Object-Oriented Design gegen Information Hiding and Encapsulation verstoßen und nach dem Keep It Simple Stupid-Prinzip gehandelt.
(Ich hoffe, ich habe einen Anfänger trotz Hinweisen nicht bewusst fehlgeleitet, aber zugleich hätte er durch die "vermeintlich" schlechtere Lösung auch auf eine besser kommen können.)
Security through obscurity - ist im weitesten Sinn nur bei deiner PIN sinnvoll - ist aber ein Prinzip, was mit OO und der Frage nach int nix mehr zu tun hat. 😉

 

[Mxxxt]

Achso, wegen groß/kleinschreibung^^

Int gibt es nicht, er möge sich mal entscheiden: int oder Integer. Es gibt auch keine rosa Einhörner ...

Naja, die wahren Einhörner sind Nashörner xD

 

[Xyz1]

Naja, die wahren Einhörner sind Nashörner xD

Sind das nicht die, die den ganzen Tag gar nix machen und sich von Schwebeteilchen und Dung ernähren?

 

[Mxxxt]

Falsch. Manipulierbar sind sie immer (private aber nur mit erheblichem Aufwand).

Es geht bei der ganzen Aktion um das Vorbeugen von Bugs. Man benutzt Setter, damit man die Werte, die einer Variable zugewiesen werden, kontrollieren und limitieren kann. Wenn du denn Füllstand eines Tanks speicherst, macht es wenig sinn, da eine negative Zahl rein zu schreiben. Also schreibt man einen Setter, der diese Überprüfung macht. Damit der Setter nicht aus versehen (absichtlich geht IMMER) umgangen wird, macht man die Variable private. Damit man sie jetzt von aussen aber noch lesen kann, benutzt man einen Getter.
Man benutzt Getter und Setter für alle Variablen, weil man zu Beginn meist nicht alle diese Einschränkungen kennt. Wenn ein Projekt viel Code hat ist es äußerst mühselig alle Zugriffe auf die Variable in Aufrufe des Getters und Setters umzuwandeln.

Naja, das mit den getter/setter hatte ich dadrüber schon erwähnt. Ich hätte es auch zusammenfassen können. Jedenfalls sind private Deklarationen nur innerhalb dieser Klasse ansprechbar, sonst brauch man halt getter und setter.

 

[Xyz1]

Die Typen belegen halt unterschiedlich viel Platz im RAM.
byte = 8 Bit
short = 16 Bit
...

Das stimmt so auch nicht. Gerade kleinere Typen können auch mehr Speicher reservieren.

Ich denke, warum int empfohlen wird, hat (hinsichtlich Speicherbelegung) zwei Gründe:
1) Der Tut Autor verwendet immer int und weiß es nicht besser,
2) int ist für die meisten Anwendungsfälle nicht zu groß und nicht zu klein.

Wenn int nicht mehr ausreicht, wäre ich mir auch bei long unsicher. Aber das kommt auf die Domäne an, wie immer.

Außerdem muss man sich fragen, in welche Richtung sich dieses Thema jetzt entwickelt ...

 

[Tobse]

Jedenfalls sind private Deklarationen nur innerhalb dieser Klasse ansprechbar

Das ist aber falsch 🙂 Über reflection kommt man an alle Member. Und letztendlich liegt das zeug sowieso nur im Speicherbereich der JVM; Code, der Zugriff auf diesen Speicherbereich hat, hat auch Zugriff auf diese Variablen. Private ist kein Sicherheitsfeature.

 

[Mxxxt]

Das ist aber falsch 🙂 Über reflection kommt man an alle Member. Und letztendlich liegt das zeug sowieso nur im Speicherbereich der JVM; Code, der Zugriff auf diesen Speicherbereich hat, hat auch Zugriff auf diese Variablen. Private ist kein Sicherheitsfeature.

Folgendes steht bei mir in den Studienmaterial:
private als Modifikator bietet maximalen Schutz: Auf derartige Datenelemente kann nur innerhalb einer Java-Klasse zugegriffen werden, ein Zugriff "von außen", d.h. aus einer anderen Java-Klasse heraus, ist nicht möglich. Gleiches gilt übringens auch für Methoden, die als "private" deklariert werden. Auch solche Methoden können nur innerhalb einer Java-Klasse aufgerufen werden , stehen für einen Aufruf "von außen" hingegen nicht zur Verfügung. Ein private Element ist Gegensatz zu einem public Element von außen nicht sichtbar.

Dann gehts mit der Kapselung weiter. Verstehe ich dich jetzt richtig, dass du dies als falsch deklarierst?

 

[mrBrown]

Folgendes steht bei mir in den Studienmaterial:
private als Modifikator bietet maximalen Schutz: Auf derartige Datenelemente kann nur innerhalb einer Java-Klasse zugegriffen werden, ein Zugriff "von außen", d.h. aus einer anderen Java-Klasse heraus, ist nicht möglich. Gleiches gilt übringens auch für Methoden, die als "private" deklariert werden. Auch solche Methoden können nur innerhalb einer Java-Klasse aufgerufen werden , stehen für einen Aufruf "von außen" hingegen nicht zur Verfügung. Ein private Element ist Gegensatz zu einem public Element von außen nicht sichtbar.

Dann gehts mit der Kapselung weiter. Verstehe ich dich jetzt richtig, dass du dies als falsch deklarierst?

Jein, für den Kenntnissstand, den man hat wenn man dies lernt, gilt das erstmal. Auf dem "normalem" Weg kommt man da auch nicht ran.
Über Reflection geht aber generell alles.

Und die Daten müssen ja auch irgendwo im Speicher stehen, wer Zugriff auf den Speicher hat, kann die sehen, egal welcher Modifier dran steht 😉

 

[Xyz1]

Folgendes steht bei mir in den Studienmaterial:
private als Modifikator bietet maximalen Schutz: Auf derartige Datenelemente kann nur innerhalb einer Java-Klasse zugegriffen werden, ein Zugriff "von außen", d.h. aus einer anderen Java-Klasse heraus, ist nicht möglich. Gleiches gilt übringens auch für Methoden, die als "private" deklariert werden. Auch solche Methoden können nur innerhalb einer Java-Klasse aufgerufen werden , stehen für einen Aufruf "von außen" hingegen nicht zur Verfügung. Ein private Element ist Gegensatz zu einem public Element von außen nicht sichtbar.

Dann gehts mit der Kapselung weiter. Verstehe ich dich jetzt richtig, dass du dies als falsch deklarierst?

Wenn man davon ausgeht, dass das System nicht kompromittiert wurde, ist das richtig. (Was es auf deinem Kenntnisstand nicht ist) Über Reflection kommt man auch nicht ohne Weiteres dran. Eine PIN liegt aber als gesalzener Hash in irgendeiner Datenbank.

So, in welche Richtung soll sich dieses Thema entwickeln? Allgemeine Philosophiestunde?

Schön fände ich es, wenn er nochmal auf meine Frage antworten würd, ob er sich auf mich bezieht; wo ich private, public und Getter/Setter weggelassen habe, und einen Teil der Geschäftslogik in den Konstruktor gemogelt habe.

 

[InfectedBytes]

Über Reflection kommt man auch nicht ohne Weiteres dran.

Das geht eigentlich recht einfach:

Field field = obj.getClass().getDeclaredField("somePrivateField");
field.setAccessible(true);
MyClass value =(MyClass)field.get(obj);
// bzw.
field.set(obj, newValue);

 

[Xyz1]

Danke, wusste nicht, dass es so einfach ist.