Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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?
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
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.
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.
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.
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.
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...
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.
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!
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?
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.
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?
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.
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.
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.
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 ...
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.
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?
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
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.
Field field = obj.getClass().getDeclaredField("somePrivateField");
field.setAccessible(true);
MyClass value =(MyClass)field.get(obj);
// bzw.
field.set(obj, newValue);