[JAVA] Klasse mehrfach aufrufen

[Stormscud]

Hallo liebe Gemeinde,

ich habe mal wieder ein Problem... In meinem Programm habe ich eine Tastatur (also ~ 70 Buttons) auf die Oberfläche gelegt. Das Programm wird später nur per Touchscreen bedient. Aufgrund des mittlerweile recht aufgeblähten Quelltextes meiner Hauptklasse würde ich gerne einige Dinge auf externe Klassen auslagern. Momentan ist es so, dass ich auf die Buttons der Tastatur einen Listener lege um die Eigabe des Nutzers abzufangen und auszuwerten.

Der Vergleich welcher Buchstabe tatsächlich gedrückt wurde soll in der Klasse Keyboard.java geschehen. Meine Hauptklasse ist die BigBag.java (hier sitzt auch der Listener).

Der Listener ist folgendermaßen aufgebaut:

class buttonPressedActionListener implements ActionListener {

@Override
public void actionPerformed (ActionEvent event) {
selectedButton = event.getActionCommand();
try {
Keyboard key = new Keyboard(selectedButton);
pressedButton = key.uiInput;
keyboardInput(); //Weiterverarbeitung der Eingabe
} catch (Exception ex) {
JOptionPane.showMessageDialog(null, ex, "Fehlermeldung", JOptionPane.ERROR_MESSAGE);
}
}
}

Die Klasse Keyboard sieht wie folgt aus (Ausschnitt):

public class Keyboard extends BigBag{
public Keyboard(String selectedButton) throws Exception{
if (selectedButton.equals("1")) {
uiInput = "1";
...

Mein Problem ist nun, dass ja jedesmal wenn eine Taste gedrückt wurde eine neue Instanz der Klasse Keyboard gestartet wird. Irgendwie scheine ich nicht zu verstehen, wie ich auf eine Klasse zugreife, ohne sie jedesmal neu zu instanzieren. Kann mir da jemand auf die Sprünge helfen?
Ansonsten habe ich nach jedem Tastendruck eine weitere Kopie meines Programms laufen :freak:

Das Problem beschäftigt mich auch schon länger, nur habe ich bisher keine Lösung gefunden.

[Baalzamon]

Hmmm... ich haue mal drei Alternativen in den Raum.

1. Mach die Klasse statisch, mit allen Vor- und Nachteilen
2. Erzeuge die Klasse in einer übergeordneten Klasse, auf die du dann per Referenz aus deinem Listener zugreifen kannst
3. Mache die Klasse zu einem Singleton, mit allen Vor- und Nachteilen

[Monger]

Da gibt es jetzt natürlich verschiedene Varianten.

Wenn deine Keyboard Klasse keine eigenen Daten hält sondern einfach irgendwas verarbeitet, dann bietet es sich an sie statisch zu machen. Es gibt eh nur ein Keyboard an einem Rechner.

Wenn sie interne Daten halten muss die von Aufruf zu Aufruf auswertest, dann musst du notgedrungen die Instanz von jedem Punkt aus zugänglich machen. Du könntest sie z.B. als Attribut deines Fensters deklarieren und beim Laden des Fensters einmalig instanziieren.
Vorallem wenn du Fensterübergreifend arbeiten willst, bietet sich eventuell auch ein Singleton Pattern an.

Edit: zu spät! :ugly:

[Gast]

class buttonPressedActionListener implements ActionListener {
private Keyboard key = new Keyboard();
@Override
public void actionPerformed (ActionEvent event) {
selectedButton = event.getActionCommand();
try {
key.setSelectedButton(selectedButton);
pressedButton = key.uiInput;
keyboardInput(); //Weiterverarbeitung der Eingabe
} catch (Exception ex) {
JOptionPane.showMessageDialog(null, ex, "Fehlermeldung", JOptionPane.ERROR_MESSAGE);
}
}
}

[Tiamat]

Mir erschließt sich ehrlich gesagt nicht der Sinn die KeyBoard Klasse in der ActionPerformed Methode zu erzeugen. Das hab ich noch nie gesehen sowas und das wird definitiv zu Verzögerungen irgendwann führen, wenn ein User wie ein irrer auf die Buttons klickt. Jedes Mal wird ne Klasse bei einem einzigsten Klick erzeugt und irgendwann meldet sich der Garbage-Collector, wenn der Ram zugemüllt wird.

Warum nicht so ?


class ButtonCarrier { // irgendne Klasse halt, die die JButtons beinhaltet

JButtons[] buttons = new JButtons[70];
String[] text = new String[70];
KeyBoard listener = new KeyBoard(this);

ButtonCarrier() {
int index = 0;
for(JButton button : buttons) {
button = new JButton(text[i++]);
button.addActionListener(listener);
}
}
}

class KeyBoard implements ActionListener {
ButtonCarrier carrier;

KeyBoard(ButtonCarrier carrier) { this.carrier = carrier); }
public void actionPerformed(ActionEvent e) {
// fallunterscheidung nach Button
}
}



So würd ich das machen, wenn ich unbedingt n externen Listener verwenden wollte. Wobei das String Array halt irgendwie noch mit Text vorinitialisiert werden muss bei meinem Beispiel.

Gruß
Tiamat

[Stormscud]

@ Gast: Damit wird immer noch jedesmal beim Aufrufen des Listeners eine neue Klasse erstellt.

@ Tiamat: Interessanter Ansatz. Allerdings wüsst ich trotzdem gerne wie das bei Java funktioniert, dass ich auf eine externe Klasse zugreifen kann, ohne jedesmal die Klasse neu zu instanzieren. Ich würde so halt ganz gerne meinen Quelltext ein wenig auf mehrere Dateien aufteilen, sodass das ganze übersichtlicher wird. Am Besten wäre ein Veranschaulichung an einem kleinen Beispiel. Das Buch "Java ist auch eine Insel" hat mir bei dem Problem leider nicht helfen können.

Danke aber auch an die Anderen für die Antworten

[PatkIllA]

@ Gast: Damit wird immer noch jedesmal beim Aufrufen des Listeners eine neue Klasse erstellt.

@ Tiamat: Interessanter Ansatz. Allerdings wüsst ich trotzdem gerne wie das bei Java funktioniert, dass ich auf eine externe Klasse zugreifen kann, ohne jedesmal die Klasse neu zu instanzieren. Ich würde so halt ganz gerne meinen Quelltext ein wenig auf mehrere Dateien aufteilen, sodass das ganze übersichtlicher wird. Am Besten wäre ein Veranschaulichung an einem kleinen Beispiel. Das Buch "Java ist auch eine Insel" hat mir bei dem Problem leider nicht helfen können.

Danke aber auch an die Anderen für die Antworten
Eine Klasse wird nicht neuerstellt sondern höchsten Instanzen der Klasse. Es tut auch nicht weh mal ein neues Objekt zu erzeugen. Man kann etliche Millionen Objekte pro Sekunde erstellen.

[Stormscud]

Das mag sein, allerdings habe ich dann halt wie gesagt nach jedem Tastendruck eine weitere Instanz meines Programms offen. Das ist absolut inakzeptabel.

[Gast]

@ Gast: Damit wird immer noch jedesmal beim Aufrufen des Listeners eine neue Klasse erstellt.

Eben nicht. key ist ein dann Attribut des ActionListeners. Wenn du nur einmal ein ActionListener erstellst und den dann an alle Buttons übergibst, dann existiert nur eine Instanz von dem ActionListener und das Atrribut wird nur einmal initialisiert.

[Tiamat]

@ Gast: Damit wird immer noch jedesmal beim Aufrufen des Listeners eine neue Klasse erstellt.

@ Tiamat: Interessanter Ansatz. Allerdings wüsst ich trotzdem gerne wie das bei Java funktioniert, dass ich auf eine externe Klasse zugreifen kann, ohne jedesmal die Klasse neu zu instanzieren. Ich würde so halt ganz gerne meinen Quelltext ein wenig auf mehrere Dateien aufteilen, sodass das ganze übersichtlicher wird. Am Besten wäre ein Veranschaulichung an einem kleinen Beispiel. Das Buch "Java ist auch eine Insel" hat mir bei dem Problem leider nicht helfen können.

Danke aber auch an die Anderen für die Antworten

Das is ganz einfach. Entweder du ne statische Methode die du über Klassenname.methode() aufrust oder eben nicht.

In dem Fall ist actionPerformed allerdings nicht statisch und das ist das Problem an der Geschichte sondern es ist eine Interface-Methode von ActionListener.

Und das Instanzen der Klasse erzeugt werden is klar. Aber mit Millionen von Objekten pro Sekunden komm ich nicht klar ;D;D;D

Nene hat da Stormscud recht, das muss echt net sein, das führt früher oder später zu delays und unnötig hohem Speicherverbrauch.

[patermatrix]

Das mag sein, allerdings habe ich dann halt wie gesagt nach jedem Tastendruck eine weitere Instanz meines Programms offen. Das ist absolut inakzeptabel.
Wie kommst du darauf?

[Stormscud]

Ich hatte beim ersten Testen ungefähr 13 oder 14 Tasten gedrückt und genau so oft hatte ich mein Programm auf einmal in der Taskleiste xD sind zwar nur ein paar KB Rab die dazu kamen, aber trotzdem...

[Tiamat]

Jetzt wird´s aber ominös

[universaL]

pack deinen code doch auf github.com / pastie.org (je nach menge). hier an code-fetzen rumzuraten ist imo etwas umständlich, vor allem da du anscheinend noch nicht soviel programmiererfahrung hast, und somit mit den Hinweisen nicht soviel anfangen kannst ;-)

[Baalzamon]

Jetzt wird´s aber ominös
Jo. :|

Wobei mir gerade noch aufgefallen ist:

Der Vergleich welcher Buchstabe tatsächlich gedrückt wurde soll in der Klasse Keyboard.java geschehen. Meine Hauptklasse ist die BigBag.java (hier sitzt auch der Listener).

und

public class Keyboard extends BigBag

lässt mich ungefähr so aussehen: :confused:

Aber unabhängig davon. Was hindert dich daran die Keyboard Klasse statisch zu machen? Scheint mir an der Stelle erstmal die einfachste Möglichkeit.

[Mr.Freemind]

Du könntest auch noch (wenn du den Listener auslagern möchtest) eine Listenerklasse schreiben, diese implementiert die Listener(Mouse,Key etc.).

Der Konstruktor der Listenerklasse bekommt dann das jeweilige Objekt was überwacht werden soll(Frame,Panel), kann man auch gerne überladen.

In der zu überwachenden Klasse(Frame, Panel) übergibst du das "this" Objekt der Listenerklasse(anstelle wo sonst immer die innere Klasse des ActionEvents steht).

So hat man eine große "Controllerklasse" die mehrere mögliche Events im Auge haben kann.

Allerdings was spricht dagegen, die einzelen Listener in der jeweiligen Klasse zu implementieren? Die anonyme innere Klasse?

[Stormscud]

Hmm das mit dem Hiochladen ist eigentlich keine schlechte Idee, allerdings weiß ich nicht, ob das mein Chef auch so sieht ;)

Naja ich denke mal ich werd heute Abend mal alles hochladen, muss aber vorher noch ein paar mehr Kommentare reinmachen. Das Programm wird Teil meiner Masterarbeit (Maschinenbau). Ich habe auch dementsprechend "gute" Programmierkentnisse :freak:

Momentan habe ich einfach alles in eine Datei geschrieben, damit habe ich keine probleme, allerdings sind es so mit Leerzeilen schon 1800 Zeilen Quelltext. Mittlerweile verlier ich auch immer mal etwas den Überblick. Liegt aber sicher auch an der sicher nicht allzu guten Struktur. Ihr werdet das Ding wahrscheinlich in der Luft zerreißen^^

[Stormscud]

Werde es, wenn ich darf^^, morgen vormittag hochladen.

[Neo69]

ich vermute, du musst dich mal mit einem Informatiker mal zusammen setzen und für deine Anwendung eine Klasssenstruktur überlegen.

[Stormscud]

So, wenn jemand versuchen will in meinem Programm durchzusteigen und mir bei meiner Problemlösung helfen möchte kann das nun tun :)

Es sind 3 Dateien:
BigBag.java
Keyboard.java
Write.java

Mittlerweile habe ich die Write und die Keyboard und die BigBag mit reingepackt, damit ist das Problem hinfällig (das hier ist die letzte Version, die noch mit dem Problem behaftet ist). Allerdings würde ich gerne mit mehreren Dateien arbeiten, damit mein Projekt nicht aus einer fetten Datei besteht. Wär also echt toll, wenn mir jemand erklären könnte wie ich in meinem Fall auf die Keyboard und die Write zugreifen kann, ohne sie ständig neu zu instanzieren.

Noch was zur Entwicklungsumgebung:
NetBeans 7.0 mit JDK und JRE 1.7.0

Alle anderen Fehler oder dreckigen Programmiermethoden könnt ihr mir auch gerne ankreiden, möchte ja aus meinen Fehlern lernen ;)

@Neo69: In meinem Freundeskreis bin ich schon der Computer/Info Fachmann xD Kann also niemanden um Hilfe bitten.

[Thunderhit]

Großer Gott... hast du noch nie was von Arrays oder Listen gehört? Diese ganzen Definitionen von Zigtausend Labels, Buttons etc. ist ja fürchterlich (und vor allem noch public).
Warum definierst du überhaupt so viele Variablen in der Klasse? Ganz sicher muss kein int i überall in der Klasse verfügbar sein.
Die Keyboardklasse...was soll das? Du prüfst ob der String im ausgewählten Button einem bestimmten Buchstaben entspricht und setzt dann irgendeine Variable auf den selben Wert... das kannst du dir doch sparen und der Variable gleich den String zuweisen im Sinne von
uiInput = selectedButton
Ansonsten... hier wäre Java 7 cool, dann kannst du ein switch/case mit dem String machen.

[Stormscud]

Ja das mit den Millionen Buttons und Labels regt mich auch auf, hatte aber bisher immer irgendwie ein Vorstellungsproblem, die in einer Schleife zu erzeugen. Tiamat hat ja auf der vorigen Seite gezeigt, wie es besser geht.

Die Keyboardklasse macht aber auch noch die Unterscheidung auf Groß- oder Kleinschreibung. Der Teil fehlt aber hier noch (aber ich werd es mal noch abändern). Ich wollte das vor allem aufgrund der Menge aus der Hauptdatei auslagern.

Aber schon mal danke für die kritischen Bemerkungen. Mir war schon klar, dass ich nicht gut programmiere :redface:

[Mr.Freemind]

Schau dir echt mal Collections an. Iterieren ist ganz simpel, da gibt es wie üblich bei Java zig Möglichkeiten(for-Schleife;for-Each-Schleife(erweiterte for-Schleife), Iterator).

Edith1: Und denke bitte echt an die Sichtbarkeiten (wie schon oben erwähnt) public ist ganz schlecht, lieber private oder wenn du innerhalb von Paketen arbeitest protected.

[Stormscud]

Naja im nachhinein betrachtet ist es doch schon recht logisch xD Aber gut das schau ich mir noch mal an, auch die Sache mit den Sichtbarkeiten. Wobei ich mit private schlechte Erfahrungen gemacht habe, als ich mit NetBeans die Buttons und andere Objekte im Oberflächeneditor gesetzt habe. Da konnte ich nicht auf die Objekte von der externen Klasse Keyboard zugreifen, da Netbeans alle Objektvariablen standardmäßig als private gesetzt hatte. Irgendwie programmiere ich eher nach Gefühl statt nach System :freak:

Aber ich werd das schon noch hinbekommen^^ Kann mir denn noch jemand erklären, wie ich auf eine externe Datei zugreife ohne diese ständig neu zu instanzieren? Also in diesem Fall auf die Klasse Keyboard?

[Thunderhit]

Indem du einfach nur eine Instanz erstellst und immer auf diese Variable zugreifst.

[Mr.Freemind]

Naja im nachhinein betrachtet ist es doch schon recht logisch xD Aber gut das schau ich mir noch mal an, auch die Sache mit den Sichtbarkeiten. Wobei ich mit private schlechte Erfahrungen gemacht habe, als ich mit NetBeans die Buttons und andere Objekte im Oberflächeneditor gesetzt habe. Da konnte ich nicht auf die Objekte von der externen Klasse Keyboard zugreifen, da Netbeans alle Objektvariablen standardmäßig als private gesetzt hatte. Irgendwie programmiere ich eher nach Gefühl statt nach System :freak:

Aber ich werd das schon noch hinbekommen^^ Kann mir denn noch jemand erklären, wie ich auf eine externe Datei zugreife ohne diese ständig neu zu instanzieren? Also in diesem Fall auf die Klasse Keyboard?

Das hat schon seinen Grund warum Netbeans die Objektvariablen auf private (http://www.tilman.de/uni/ws03/alp/java.php)gesetzt hat, es soll ja schließlich nicht von außen auf die Objekteigenschaften zugegriffen werden(ansonsten gibt es dafür getter und setter (http://de.wikipedia.org/wiki/Zugriffsfunktion) Methoden), dies kann nämlich sehr gefährlich werden.

Es ist evtl. mit Spatzen auf Kanonen geschossen aber google mal nach MVC (http://openbook.galileocomputing.de/oo/oo_06_moduleundarchitektur_001.htm)(Model View Controller), dies ist ein Pattern und eigentlich ein muss wenn es um Klassen geht die reine Kontroll-Funktionalität aufweisen und einem View (GUI).

[Tiamat]

Hi, da es deine Masterarbeit ist, will ich dir n paar Tips geben, weil ich zufällig Info-Student bin.

1. Vererbung
Ist legitim, wenn man mehrere Klassen hat, die sich um minimale Attribute unterscheiden und thematisch zusammengehören. Dann lässt sich eine (abstrakte) Basisklasse definieren, die die meisten Attribute beinhaltet und vor dann die genaueren Klassen ableiten.

Was du hier machst ist, du schmeißt die Anwendungslogik und die View in eine Basisklasse ( so was wird auch God-Class genannt), von der dann alle weiteren Klassen ableiten und sogar noch mehr God-like sind). Ich schätze mal der Gedanke dahinter war, das du bequem an die Attribute von BigBag rankommst, aber damit hast du dir keinen Gefallen getan.
Das ist der Grund, wieso bei dir mehrere Programminstanzen in der Taskleiste auftauchen.

Jedes Mal wenn ein Button geklickt wird, wird eine neues KeyBoard Objekt instanziert, das wegen der Basisklasse BigBass zugleich ein JFrame beinhaltet.

1. Fehler : Diese Benutzung der Vererbung( als deine Art und Weise ) wird bei deinen Prüfern ganz schlecht ankommen.

2. Fehler : Jeder Button der gedrückt wird ist zugleich ne neue Programminstanz. Das kommt noch schlechter bei den Prüfern ( = Profs ) an und ich das wird die Note ziemlich runterreißen.

2. BigBag leitet von JFrame ab, du nutzt die Basisklasse aber gar nicht, sondern du erzeugst manuell einen JFrame. Entweder du nutzt die BasisKlasse oder du erzeugst manuell einen JFrame und dann brauchst du auch nicht von JFrame ableiten. Das macht keien Sinn. Kann man als Schönheitsfehler sehen, wenn man tolerant ist.

3. Warum werden alle GUI-Elemente mit aufsteigender Zahl bezeichnet, die Buttons aber von 1-X und von 100-Y ,welchen Sinn hat das ?

4. Wurde schon mal gesagt. Pack diese GUI Elemente in Arrays/Listen und iterier durch. Dadurch lässt der Programmcode wesentlich reduzieren.

5. Ehrlich gesagt mir gefällt da keine Klasse, das macht alles n ziemlich chaotischen Eindruck.

[Neo69]

Er ist doch MaschBau Student, von daher wird der Code an sich vermutlich nicht in die Bewertung eingehen, sondern ist eher Mittel zum Zweck. Das wird der Betreuer ja hoffentlich auch klar gemacht haben, wie wichtig das ist.

[Tiamat]

Ich bin da anderer Meinung. Das is ne Masterarbeit und da verlangt man schon, dass man sich bei den Dingen mit denen man arbeitet konform ist und interdisziplinär arbeiten kann.
Und das was bei dem Code falsch läuft, hätte man sich mit Leichtigkeit erspart, wenn man nur wenige Stunden z.B Java ist eine Insel gelesen hätte. Thema Vererbung, Thema GUI-Programmierung und ein paar Fragen in Foren z.B gestellt hätte.

Und die Profs wissen sowas.

[Stormscud]

Erstmal nochmals danke an Tiamat, dass du dir Zeit für meinen wirklich recht chaotischen Code genommen hast ;)

@Neo69: Ich bin mir auch nicht so sicher wie gut mein Prof. sich auf die Programmierung versteht. Wir hatten zwar ein Semester Java bei ihm, aber das war irgendwie sehr einfach gestrikt und eher ne Überblicksveranstaltung.
Sprich, die Programmierkentnisse, die wir als Master im Maschinenbau haben sind absolut rudimentär.

@Tiamat:
1. Ich habe über Vererbung bereits in dem genannten Buch gelesen, ob ich wirklich alles richtig verstanden habe weiß ich nicht. Letztenendes war vor allem die beschränkung auf Einfachvererbung von Bedeutung für mich.

Ich habe bereits vorher ein wenig programmiert, allerdings war das mit Visual Basic 6.0 :freak: Irgendwie hänge ich im Kopf glaub ich immer noch ein wenig in der Sprache...

2. Ist mir noch gar nicht aufgefallen oO Glaube das ist ein Überbleibsel vom GUI Builder, dass ich übernommen habe. Copy&Paste...

3. Ich hatte die Buttons der Tastatur nur für mich einfach auf 100 aufwärts gelegt. Zur besseren Unterscheidung. So hab ich unter der 100 noch Platz weitere einzufügen und so ein Trennung zwischen Tastatur und den restlichen Buttons der Oberfläche. Also nicht weiter tragisch denke ich.

4. Wenn ich noch Zeit finde, werd ich das auf jedenfall noch tun. Stand schon auf meiner Agenda ;)

5. Da hast du, wie schon geschrieben, auch vollkommen recht. Wenn ich zu Anfang gewusst hätte, worauf ich mich hier einlasse mit Java hätte ich mir ein aktuelles Visual Basic besorgt. Aber irgendwann im Laufe der Entwicklung kann bzw. will man dann nicht mehr zurück. Die Zeit die man reingesteckt hat soll ja für diesen einen Fall nicht umsonst gewesen sein.

Momentan hab ich auch nur noch eine Java Datei. Damit hab ich das Instanzenproblem erstmal beseitigt, allerdings hab ich nun eine fette unübersichtliche Datei. Gefällt mir auch nicht, muss aber erstmal genügen.

Das Grundproblem bei meinem Programm ist doch folgendes: Nach der Konstruktion hab ich einfach aus dem Nichts heraus angefangen ein Programm zu schreiben, ohne mir groß einen Kopf gemacht zu haben, wie ich es aufbauen will. Da liegt denke ich der Hund begraben. Unzureichendes Wissen über Java kam noch hinzu.
Hab zuerst einen Prototyp gebaut mit dem GUI Builder um die Kommunikation mit dem Messverstärker hinzubekommen. Dann hab ich das programm schrittweise erweitert. Aber eben so, wie mir grad der Kopf stand. Und wenn ein Problem auftauchte hab ich geschaut wie ich es lösen kann. Größtenteils waren das einfach nur Probleme, die aus dem mangelndem Sprachverständnis heraus entstanden sind. Und später hat es mir mit dem GUI Builder und seinem Grid-Bag-Layout (?) gereicht und ich hab alles von Hand programmiert. Alles in allem hab ich schon einige Haare an dem Programm gelassen.

[PatkIllA]

@Tiamat:
1. Ich habe über Vererbung bereits in dem genannten Buch gelesen, ob ich wirklich alles richtig verstanden habe weiß ich nicht. Letztenendes war vor allem die beschränkung auf Einfachvererbung von Bedeutung für mich.Wieso siehst du das als Beschränkung an? Sinnvolle Vererbung ist ein mächtiges Werkzeug und da legt man sich mit mehrfachvererbung ganz schnell ein Ei.
Der eingeschränkte Zugang zu Variablen/Methoden von Klassen nimmt dir auch keine Möglichkeiten sondern erlaubt erst ein System in sinnvolle Einzelteile zu zerlegen und es wartbar und verständlich zu halten.
5. Da hast du, wie schon geschrieben, auch vollkommen recht. Wenn ich zu Anfang gewusst hätte, worauf ich mich hier einlasse mit Java hätte ich mir ein aktuelles Visual Basic besorgt.Ein aktuelles Visual Basic hat die sehr ähnliche Konzepte wie Java. Die Sprache ist nebensächlich. Von dem was ich hier so lese, fehlt dir die Erfahrung zur Objektorientierung.
Aber irgendwann im Laufe der Entwicklung kann bzw. will man dann nicht mehr zurück. Die Zeit die man reingesteckt hat soll ja für diesen einen Fall nicht umsonst gewesen sein.
Vermurksten Code retten zu wollen ist oft mehr Aufwand als es mit den Erfahrungen noch mal neuaufzusetzen. Wenn der Code für mehr als einen Hack bei einer Präsentation reichen soll ist es enorm wichtig strukturierten, verständlichen und zu einem Mindestmaß kommentierten Code zu haben.
Eine bekannte, die in einer Firma für chemische Messgeräte gearbeitet hat, hat auch öfter die Krise bei der Steuerungssoftware bekommen.

[del_4901]

Vermurksten Code retten zu wollen ist oft mehr Aufwand als es mit den Erfahrungen noch mal neuaufzusetzen. Wenn der Code für mehr als einen Hack bei einer Präsentation reichen soll ist es enorm wichtig strukturierten, verständlichen und zu einem Mindestmaß kommentierten Code zu haben.
Eine bekannte, die in einer Firma für chemische Messgeräte gearbeitet hat, hat auch öfter die Krise bei der Steuerungssoftware bekommen.
Jain, denn zumindest (in meiner professionellen) Karriere moechte ich Niemanden Unwissenheit oder Inkompetenz vorwerfen. Der Code ist also nicht ohne Grund zu dem geworden was er ist. Haeufig sind das Sonderfaelle die erst durch vielfaches testen ans Tageslicht gekommen sind. Wenn du diesen Code komplett wegschmeisst, dann schmeisst du auch den ganzen Testaufwand mit weg. Man sollte sich also schon die Muehe machen den alten code zu versten und notfalls zu refaktorisieren, bevor man Ihn wegschmeisst.

[Neo69]

Daher auch von mir der Rat, sich mit jemanden, der sich auskennt am Anfang eine Programm-/Klassenstruktur zu überlegen, aber da hat sich ja im Bekanntenkreis leider keiner angeboten.

[del_4901]

Daher auch von mir der Rat, sich mit jemanden, der sich auskennt am Anfang eine Programm-/Klassenstruktur zu überlegen, aber da hat sich ja im Bekanntenkreis leider keiner angeboten.
Sich zu zeitig Gedanken ueber eine Klassenstruktur zu machen fuehrt nur allzuoft zu Overengineering. Daher mein gut gemeinter Rat: Keep it simpel as long as you can and refactor where nessesary.

[Mr.Freemind]

Sich zu zeitig Gedanken ueber eine Klassenstruktur zu machen fuehrt nur allzuoft zu Overengineering. Daher mein gut gemeinter Rat: Keep it simpel as long as you can and refactor where nessesary.

Sehe ich anders, gerade bei solch einer Situation wie beim TS wäre es sinnvoll einmal Struktur in den Code zu bringen und ihn auch zu dokumentieren, ansonsten braucht er sich nicht wundern wenn ihm das Ding irgendwann um die Ohren fliegt.

[del_4901]

Sehe ich anders, gerade bei solch einer Situation wie beim TS wäre es sinnvoll einmal Struktur in den Code zu bringen und ihn auch zu dokumentieren, ansonsten braucht er sich nicht wundern wenn ihm das Ding irgendwann um die Ohren fliegt. Dem TS fehlt es vorallem an Erfahrung, und wie soll er die bekommen wenn man Ihn nicht auch mal was Falsch machen laesst?

[Mr.Freemind]

Dem TS fehlt es vorallem an Erfahrung, und wie soll er die bekommen wenn man Ihn nicht auch mal was Falsch machen laesst?

Da gebe ich dir grundsätzlich Recht; Programmieren "lernt" man durch Programmieren. Ich bin davon ausgegangen, dass er über das Grundwissen bei OO verfügt; habe aber eben gelesen, dass diese quasi nicht vorhanden sind. Damit wäre mein Vorschlag natürlich "mit Spatzen auf Kanonen geschossen".

Wie oben beschrieben sollte er sich zuerst mit den Basics auseinandersetzen:

- OOP vs. Imperativ/Prozedural.
- Klassen, Objekte, new.
- Java kennt nur "CallByValue"
- this
- Methoden.

- Grunddatentypen, Operatoren, alles Signed, casts.
- Boxed-Datentypen
- Arrays
- Strings
- Ueberladen von Methoden u. Konstruktoren, Standardkonstruktor
(early binding -> Polymorphie)

- Vererbung -> Alles erbt von Object, extends
- Superkonstrukturaufrufe
- Ueberschreiben
(late binding -> Polymorphie)
- Annotation @Override
- toString
- Equals

- abstrakte Klassen
- Interfaces, implements, extends
- Kovariante Rueckgabetypen
- Garbage Collection
- finalize

- Container: Collections, Maps
- ArrayList
- LinkedList
- HashSet
- TreeSet
- HashMap
- TreeMap
- Comparable
- Comparator

Wenn das Zeugs soweit passt, sollte man tatsächlich aber dann anfangen sich um Strukturen im Code Gedanken zu machen.

[PatkIllA]

Jain, denn zumindest (in meiner professionellen) Karriere moechte ich Niemanden Unwissenheit oder Inkompetenz vorwerfen.
Das muss man ja nicht automatisch als Vorwurf sehen. Kann man ja zugeben, wenn einem die Erfahrung fehlt. Von dem was wir am Anfang in WPF gemacht haben, haben wir auch fast alles noch mal neugemacht, nachdem die ersten Erweiterungen machen mussten.
Der Code ist also nicht ohne Grund zu dem geworden was er ist. Haeufig sind das Sonderfaelle die erst durch vielfaches testen ans Tageslicht gekommen sind.Häufiger dürfte sein,dass da irgendwas runtergehackt wurde und das wie ein Mikadohaufen bei der nächsten Anforderung in sich zusammenfällt.
Wenn du diesen Code komplett wegschmeisst, dann schmeisst du auch den ganzen Testaufwand mit weg. Man sollte sich also schon die Muehe machen den alten code zu versten und notfalls zu refaktorisieren, bevor man Ihn wegschmeisst.Schlechter Code ist in aller Regel auch schlecht getestet worden. Bei den extremeren Fällen, die mir so untergekommen ist ist dann aber so verschränkt, dass bei der nächsten Änderung der alte Testaufwand wertlos ist, weil die Strukturlosigkeit überhaupt nicht abschätzen lässt was davon betroffen ist.
Bei einer größeren Neustrukturierung würde ich dann eher auf der grünen Wiese anfangen und die Teile rüberziehen, die man gebrauchen kann.

@Mr.Freemind
Da fehlen auf jeden Fall noch Exceptions. Da gibt es auch die nettesten Sachen insbesondere die beliebte Methode, einfach alle Exceptions wegzufangen und keine Behandlung zu machen. Aus einem mir nicht verständlichen Grund kommen die in den allermeisten Tutorials erst in den letzten Kapiteln vor.

[Mr.Freemind]

@Mr.Freemind
Da fehlen auf jeden Fall noch Exceptions. Da gibt es auch die nettesten Sachen insbesondere die beliebte Methode, einfach alle Exceptions wegzufangen und keine Behandlung zu machen. Aus einem mir nicht verständlichen Grund kommen die in den allermeisten Tutorials erst in den letzten Kapiteln vor.

Da haste natürlich Recht, habe ich vorhin in der Eile vergessen. Exceptions sind definitiv sehr wichtig und werden tatsächlich erst am Ende immer behandelt und dann auch nur das Standardzeugs, was ich sehr nett finde ist, dass schreiben von eigenen "Fehlerbehandlungs-Klassen" (wenn es sich anbietet) wird aber imo in den wenigsten Büchern erläutert.

[del_4901]

Häufiger dürfte sein,dass da irgendwas runtergehackt wurde und das wie ein Mikadohaufen bei der nächsten Anforderung in sich zusammenfällt. Damit suggerierst du ja wieder Inkompetenz/Nachlaessigkeit, und das ist dein erster Fehler!
Schlechter Code ist in aller Regel auch schlecht getestet worden. Also das kann ich nicht ganz nachvollziehen, weil der Typ in der QA schon gewissenhaft testen sollte. Oder moechtest du diesem auch Inkompetenz/Nachlaessigkeit vorwerfen?

[PatkIllA]

Damit suggerierst du ja wieder Inkompetenz/Nachlaessigkeit, und das ist dein erster Fehler!Bei den ersten Projekten muss ja noch Erfahrung sammeln und da sollte sowohl dem Vorgesetzen als auch dem Entwickler klar sein, dass da kein Geniestreich bei rum kommt.
Es gibt aber auch Leute, die trotz Code reviews, Coding Conventionen, Fortbildungen immer wieder die gleichen Fehler machen und da muss man irgendwann auch einmal den Schlußstrich ziehen.
Also das kann ich nicht ganz nachvollziehen, weil der Typ in der QA schon gewissenhaft testen sollte. Oder moechtest du diesem auch Inkompetenz/Nachlaessigkeit vorwerfen?Bei nennenswerten Änderungen müssen eh sämtliche vorherige Tests wiederholt werden. Und gerade die Software mit einer riesigen Zentralklasse am besten noch als Singleton sind ein Garant dafür, dass es bei kleinen Änderungen wie ein Kartenhaus zusammenfällt.
Wenn du Kritik automatisch mit Vorwürfen gleichsetzt, frage ich mich wie ihr es hinbekommt immer alles richtig zu machen...

[Monger]

Hier prallen ziemlich unterschiedliche Philosophien zusammen. Würde gerne darauf eingehen, aber ich glaube wir verzetteln uns dann.

Das Grundproblem bei meinem Programm ist doch folgendes: Nach der Konstruktion hab ich einfach aus dem Nichts heraus angefangen ein Programm zu schreiben, ohne mir groß einen Kopf gemacht zu haben, wie ich es aufbauen will. Da liegt denke ich der Hund begraben. Unzureichendes Wissen über Java kam noch hinzu.
Es wird sehr, SEHR selten Software geschrieben, von der man bereits am Anfang genau weiß wie sie funktionieren wird und wozu sie da ist.

Es gibt da auch in der Theorie derzeit einen gewissen Wandel. Derzeit gibt es zwei Standpunkte die miteinander konkurrieren: die einen sagen: Vorbereitung und möglichst klare Strukturierung sind das A und O. Die anderen sagen: Vorbereitung bringt eh nix, weil man ja nicht weiß was man tut. Wichtig ist, dass man seine Planung regelmäßig anpassen kann.

Auf dich übertragen: es ist völlig okay, sich erstmal planlos ins Getümmel zu stürzen, wenn du dann auch regelmäßig bereit bist, deinen Code wegzuwerfen und neu zu machen. Das klingt erstmal frustrierend, aber die Praxis zeigt, dass sobald du erstmal wirklich verstanden hast was du wie tun willst, ist die Umsetzung trivial. Etwas woran du dich beim ersten Versuch eventuell Monate gequält hast, ist dann beim zweiten mal in wenigen Tagen runtergehackt.

Es gibt verschiedene Konzepte, die einem sowas erleichtern. Eins hast du selber schon benutzt: mit Prototypen kann man Themen relativ gut isoliert betrachten und ausprobieren. Wenn ein Prototyp Daten erfordert die noch nicht implementiert sind, macht man ganz gerne Mock-ups, also Dummy Implementierungen die mal schnell dahin gerotzt sind, damit man mal wenigstens irgendeinen Wert sieht.

Das ist wie ein Bildhauer, der erstmal jeden Aspekt seiner Statue modelliert und testet, bevor er sich dann an das Gesamtobjekt macht. Du glaubst doch nicht, dass ein antiker Künstler mal so nebenbei an einem Nachmittag die Venus von Milo aus dem Stein rausgeklopft hat. So ein Bildhauer hat unzählige halbfertige Füße, Hände und Köpfe in seinem Atelier stehen, bevor er sich an ein gesamtheitliches Werk macht.

[Stormscud]

Hmm ja, doch das klingt alles sehr logisch :)
Über Künstler hab ich mir generell noch keinen Kopf gemacht, wie die zu ihren Kunstwerken kommen^^

Aber ich sollte unbedingt den Quelltext bereits bei der Entstehung ausführlich dokumentieren, merke gerade, dass ich doch öfter die Suchfunktion nutzen muss um noch durchzublicken wann ich welche Variable wo und wofür verwende :freak: Bin nämlich grad beim kommentieren und hab den Code bisher nur unzureichend kommentiert.

[PatkIllA]

Wenn man die Aufgaben und damit die Variablen auf mehreren Klassen verteilt, fällt einem auch eher wieder ein wofür was gut ist. Das gilt insbesondere wenn man sich in fremden Code einarbeiten muss. Da ist man über abgrenzte Gebiete die man nach und nach erfassen kann sehr dankbar.

[Monger]

Bin nämlich grad beim kommentieren und hab den Code bisher nur unzureichend kommentiert.
Ich kommentiere meinen Code normalerweise gar nicht. Ich kommentiere die API, d.h. öffentliche Klassen und Methoden, aber ansonsten benutze ich Kommentare nur zur Markierung von Hacks, d.h. Implementierungsbesonderheiten die sich ohne bestimmte interne Kenntnisse nicht nachvollziehen lassen.

Kommentare sind kein Heilmittel für schlechten Code!


merke gerade, dass ich doch öfter die Suchfunktion nutzen muss um noch durchzublicken wann ich welche Variable wo und wofür verwende :freak:

Da wären wir dann wieder an dem Punkt "so schreiben, dass Änderungen möglichst schnell und einfach machbar sind". Das erreichst du am einfachsten, indem du von vorneherein den Sichtbarkeitsbereich deines Codes so weit einschränkst wie nötig. Weil wenn deine Variable nirgendwo sonst verwendet werden kann, musst du auch nicht nach Verwendungsstellen suchen. Sprich: Variablen grundsätzlich mal nur lokal deklarieren, und sie erst zum Klassenattribut machen wenn es wirklich gute Gründe dafür gibt. Genauso mit Methoden und Attributen: erstmal grundsätzlich als private deklarieren, und dann bei Bedarf schrittweise (aber vorsichtig) aufbohren. Mit etwas Routine macht es sogar Sinn, innerhalb einer Methode noch weiter den Sichtbarkeitsbereich herunterzubrechen (z.B. Variablen die nur innerhalb einer Schleife verwendet werden auch nur dort deklarieren).

Wenn plötzlich alles an einem Objekt public ist, ist das ein Hinweis darauf dass möglicherweise die Trennlinien zwischen verschiedenen Themen doch nicht da liegen wo man sie beim Klassendesign vermutet hat.