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.
Wann muss man eine Variable mit set-/get-Methoden in eine Bean schreiben?
ich habe ein kleines Java-Programm in Netbeans geschrieben (Webanwendung).
Ich habe folgende Variable:
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
Diese Variable bleibt immer gleich.
Kann ich diese Variable nun einfach einmal in der Page1.java deklarieren und initialisieren und über df drauf zugreifen:
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
z.B. String s = df.toString();
oder muss ich die Variable in der ApplicationBean deklarieren und mit set- und get-Methoden auf die Variable zugreifen:
private SimpleDateFormat df;
public SimpleDateFormat getDf() {
return df;
}
public void setDf(SimpleDateFormat df) {
this.df = df;
}
und diese dann in der init() initalisieren: df = new SimpleDateFormat("yyyy-MM-dd");
und über die getMethode darauf zugreifen: String s = ApplicationBean1.getDf().toString();
???
Bin Anfänger und bin mir noch unsicher, wann ich Variablen in die Beans mit set- und get-Methoden schreiben muss und wann ich Variablen einfach in der Page1.java lassen kann. Hat dazu vielleicht jemand einen allgemeinen Tip?
Variablen werden immer dort deklariert wo sie hingehören. Wenn deine DateFormat für die ganze Applikation verwendet werden soll, dann kannst Du sie in Deine ApplicationBean werfen und einen getter dazu bauen. Wenn das Format nur zur Page1-Klasse gehört (was auch immer die tut), dann solltest Du sie dort deklarieren.
In aller Regel schreibt man alles mit get- und set-Methoden was außerhalb einer Klasse benutzt wird. Bei booleans weicht man beim getter ein kleines bisschen ab und nimmt statt getVisible() isVisible().
Außerdem: Tu Dir ein paar Gefallen... Die Methode hieße besser "getDefaultDateFormat()" oder "getSharedDateFormat" und Deine ApplicationBean-Klasse benötigt doch auch keine "1" im Namen. Und "Page1" ist auch kein guter Name. Immer alles so benennen wie es inhaltlich Sinn ergibt. Stell Dir stets vor, Du musst in einem Jahr verstehen was etwas tut und wofür es da ist.
Für diesen Fall sollte man ja auch immer eine Doku erstellen, aber zu viele sind leider zu faul... Ich bilde da sicher keine Ausnahme, aber ich bemühe mich!
>> Für diesen Fall sollte man ja auch immer eine Doku erstellen, aber zu viele sind leider zu faul... Ich bilde da sicher keine Ausnahme, aber ich bemühe mich!
Eigentlich spart man sich die Doku und schreibt sauberen, aussagefähigen Code
nur was willst du bei einem blutigen Anfänger machen, der vielleicht gerademal so eine If-Schleife enträtseln kann, auch nur weil er weiß, dass If englisch für "falls" ist...
Insofern, gerade bei größeren Projekten ist eine Doku schon sehr wichtig.
Is richtig, da geb ich voll und ganz recht. Man sollte schon beides machen, gut lesbaren Code schreiben und (gerade bei größeren Projekten, bei kleinen kohnt das noch nich) eine Doku mitliefern. Dient einfach der Benutzerfreundlichkeit, wenn ein anderer Entwickler ran muss. Dann brauch er nich den ganzen Code lesen sondern nur die Doku (erstmal zumindest).
Meist hat man nicht mal genug Zeit sauberen Code zu schreiben, geschweige denn Änderungen zwischen Code und Doku zu synchronisieren.
Moderne (agile) Methoden (zB Scrum, XP) haben sich daran angepasst.
Da besteht die Doku hauptsächlich aus:
1. sehr sauberem Code
2. Unittests
Dazu gehört auch, dass keine Kommentare im Quelltext sind, da sie "schlechten" Code Dokumentieren (Javadoc mal ausgenommen, da müssen aber mindestens die Exceptions rein)
Wir sind in unserem kleinen Entwicklerteam gerade dabei mal Scrum auszuprobieren und ich schreibe darüber auch meinen Praxistransferbericht. Mal schauen, ob es wirklich so viel bringt und wie einfach die Umsetzung ist.
Direkt einen außenstehenden SCRUM Master haben wir nicht.
Sind nur wir drei und das Projekt was wir haben ist erstmal nur als Forschungsprojekt gedacht...
Als visuelle Hilfe nutzen wir TargetProcess, wenn es dir was sagt.
Javadoc schreibe ich eigentlich für jede Methode die protected oder public ist. Dafür geht bei mir circa 5% der Entwicklungszeit drauf und die sind's mir wert. Ich habe mir angewöhnt, dass immer ein Kommentar an jedem Argument steht das null sein darf. Nach meinem Geschmack sollte in der Javadoc einer Methode auf jeden Fall erwähnt sein,
was die Methode tut
[HIGHLIGHT="Java"]/** Appends the given String to a given string builder. */[/HIGHLIGHT]
welche Parameter null sein dürfen und was dann passiert (meist ist das nicht offensichtlich)
[HIGHLIGHT="Java"]/** @param appendTo the string builder to append to, if {@code null} a new
string builder will be created */[/HIGHLIGHT]
in welche Fällen der Rückgabewert vom Normalfall abweicht
[HIGHLIGHT="Java"]/** @return the given string builder, or a new string builder, if
{@code appendTo} was {@null} */[/HIGHLIGHT]
welche Exceptions in welchem Fall geworfen werden
[HIGHLIGHT="Java"]/** @throws IllegalArgumentException if the given string was {@code null} */[/HIGHLIGHT]
sofern es auf die Methode zutrifft und nicht offensichtlich ist, eine Notiz für überschreibende Methoden
[HIGHLIGHT="Java"]/** Note: all other {@code appendTo()} methods are delegating to this
method. If subclassing this class, it is usually safe to override
this method and leave all others untouched. */[/HIGHLIGHT]
Kommentare innerhalb des Quelltextes benutze ich meist, wenn
von vornherein abzusehen ist, dass an einer bestimmten Stelle eine Optimierung sinnvoll wäre, diese aber (aus Zeitgründen, oder um erstmal vorwärts zu kommen) erst später eingebaut werden soll
[HIGHLIGHT="Java"]/* TODO: hash the last 1000 client IDs to speed-up reconnect -- 20090226 Ebenius */[/HIGHLIGHT]
eine Methode geändert werden soll, sobald ein neueres Framework verfügbar ist (derzeit muss ich zum Beispiel meist noch mit Java 5 kompatibel programmieren)
[HIGHLIGHT="Java"]/* FUTURE_JRE6: use AWTs new SplashScreen-Class -- 20090226 Ebenius */[/HIGHLIGHT]
ein bestimmter Teil des Codes einen Fehler beinhaltet der aus irgendwelchen Gründen nicht sofort behebbar ist
[HIGHLIGHT="Java"]/* FIXME: This call ends in a deadlock if some strange condition is met -- 20090226 Ebenius */[/HIGHLIGHT]
Ein bestimmter Teil eines Quelltexts aus nicht ersichtlichem Grund hinzugefügt wird
[HIGHLIGHT="Java"]/* The busy-flag must be ERASED BEFORE the call to doIt() is made;
otherwise strange stuff might happen */[/HIGHLIGHT]
Ein bestimmter Teil eines Quelltexts einen Workaround für einen Bug (ob nun aus eigenen oder aus fremden Bibliotheken spielt keine Rolle) enthält
[HIGHLIGHT="Java"]/* WORKAROUND: #1067 [Bug short description]
Savely removes all listeners prior to reinstalling the UI -- 20090226 Ebenius */[/HIGHLIGHT]
Schlechten Code zu dokumentieren und/oder kommentieren ist ganz besonders dann keine Zeitverschwendung, wenn man ihn nicht einfach ändern kann (Bibliothek in der Firma, wird x-mal verwendet, man kann die Design-Fehler nicht einfach rauswerfen) aber gerade auf die Nase gefallen ist und heraus gefunden hat warum. Wer dann nicht dokumentiert, ist selbst schuld.
>> Schlechten Code zu dokumentieren und/oder kommentieren ist ganz besonders dann keine Zeitverschwendung, wenn man ihn nicht einfach ändern kann (Bibliothek in der Firma, wird x-mal verwendet, man kann die Design-Fehler nicht einfach rauswerfen)
Wieso kann man den nciht einfach ändern?
Zumindest eine neue Version der Lib sollte doch möglich sein, denn refactoren dauert nicht viel länger als Dokumentieren, korrigiert Probleme aber nachhaltig.
>> Schlechten Code zu dokumentieren und/oder kommentieren ist ganz besonders dann keine Zeitverschwendung, wenn man ihn nicht einfach ändern kann (Bibliothek in der Firma, wird x-mal verwendet, man kann die Design-Fehler nicht einfach rauswerfen)
Wieso kann man den nciht einfach ändern?
Zumindest eine neue Version der Lib sollte doch möglich sein, denn refactoren dauert nicht viel länger als Dokumentieren, korrigiert Probleme aber nachhaltig.
Ich stimme Ebenius zu.
Ich denke dabei nur an unseren momentanen Workaround zum MySQL JDBC Encoding Bug.
Nun sind wir hier nur mit 2 Programmierern an dem Projekt, wenn aber mehr Programmierer dabei sind, wieso sollte man die Anderen nicht mit Kommentaren drauf hinweisen.
Und eine Lib muss nicht zwangsläufig nur in einem Projekt werden, womit ich diese nicht zwangsläufig mal nebenbei austauschen kann, nur weil ich gerade die Fehlersituation getroffen habe.
Du kannst ne Menge Fehler nicht einfach ausbügeln nur weil Du dazu Lust hast. Und ob Refactoring trivial oder komplex ist, hängt ja wohl deutlich von Art und Schwere des Fehlers ab, oder? Außerdem unterliegen API-Änderungen oft Beschränkungen von Versionierungsmodellen. Zum Beispiel: Die API darf sich erst in der nächsten Major-Version ändern. Was aber alles noch in der nächsten Major-Version ändert liegt vielleicht gar nicht in Deiner Hand. Die Dokumentation zu verbessern kann aber durchaus einfach in einem neuen Release mit selber Major-Version passieren...
Und noch viele andere Szenarien würden mir einfallen, in denen alte Fehler eben nicht einfach behoben werden können, die Fallstricke aber durchaus tiefer gelegt werden können, indem man kommentiert und dokumentiert.
Schlechter Code sollte in meinen Augen sogar besonders gut dokumentiert werden. Das macht ihn überhaupt nicht besser, aber oft wesentlich weniger gefährlich.
Vielleciht bin ich ja nur verwöhnt von Maven2, da kann exakt einstellen welche Version der lib man will, branching & releasing etc sind auch kein Problem mehr (max 2-3 zeilen in der shell), so dass im "Hausinterne" jars ohne weiteres geändert werden können, egal ob sie nur in 1 oder 100 Projekten verwendet werden
Jedes Projekt benutzt halt die Version die es braucht, wenn alte Projekte noch eine alte/fehlerhafte Version brauchen, nimmt man die eben.
Externe libs mit Bugs sind eine andere Sache, da reicht aber oft ein link in das Issuemanagement tool der lib.
Bis jetzt sehe ich immer noch kein Problem damit schlechten Code zu refactoren anstatt zu kommentieren, denn letzteres ist eben zeitverschwendung imho.
Genau. Und wenn in einem dieser Projekte jemand die fehlerhafte/schlechte Version einer API benutzen muss, wäre es doch super, wenn er wenigstens in der Schnittstellenbeschreibung Hinweise auf die Probleme fände.
Wann immer man einen Fehler problemflos beheben kann statt ihn zu dokumentieren, sollte man das tun. Wenn man's nicht kann, sollte man wenigstens vernünftig dokumentieren. Oft macht man sogar beides: Aktualisiert die Schnittstellenbeschreibung für den alten branch und behebt den Fehler im HEAD...