Problem bei Java ArrayList Programmierung

Problem bei Java ArrayList Programmierung (30 Beiträge, 530 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Da ich im ersten Studienjahr auch das Programmieren unter Java als Pflichtveranstaltung habe, habe ich nun eine Frage an euch bezüglich ArrayLists.

Hier ist die Angabe des Beispiels:
http://666kb.com/i/civsccl4l007rhg1l.gif

So sieht meine Klasse Fehler aus:

hosted by 666kb.com

Und meine Klasse Registrierung. Doch ab Zeile 18 habe ich ehrlich gesagt nicht wirklich einen Plan, wie ich das so hinbekomme, dass bei bereits vorhandenem Fehlertyp in der ArrayList nur dessen Anzahl erhöht wird und ansonsten der neue Fehlertyp samt Anzahl einen neuen Eintrag in der ArrayList erhält (dementsprechend hoffnungslos falsch wird meine Klasse ab Zeile 18 auch sein).

hosted by 666kb.com

Könnte mir von euch jemand helfen, das richtigzustellen?

Ein paar Hinweise:
1. Die Variablennamen "fe" und "an" sollten IMHO bessere Namen bekommen

.
2. Die Klasse Registrierung braucht keine eigene Anzahl, die Anzahl pro Fehlertyp ist eh in der Klasse Fehler gespeichert.
3. Die Variable "elemente" in der Schleife sollte besser "element" heißen, es handelt sich doch im Körper der Schleife um nur ein Element oder?
4. Ich nehme an gibAnzahl und getAnzahl sind ident...ich würde bei getAnzahl und getFehlertyp bleiben.
5. Im if-Zweig rufst du die add-Methode vom Fehler-Objekt element auf.
6. Im else-Zweig musst du zuerst ein neues Fehler-Objekt erzeugen (mit new), im Konstruktor den fehlertyp mitgeben und anschließend noch die add-Methode mit der anzahl aufrufen. Dieses Objekt kannst du dann der Liste hinzufügen.
7. Bei der Registrierung.getAnzahl-Methode musst du (wohl oder übel wieder mit einer Schleife) dir das richtige Fehler-Element aus der ArrayList suchen und dessen Anzahl zurückliefern, wenn es gefunden wurde.

Eleganter lösen könnte man das ganze mit einem Dictionary statt einer ArrayList (Key = Fehlertyp, Value = Fehler-Objekt). Dann könnte man sich die ineffizienten Schleifen sparen.

Dictionary

In Java bitteschön ein Implementierung des Map Interfaces wie HashMap, Dictionary in Java ist deprecated.

test

OK danke...ich programmiere schon lange kein Java mehr

Du glücklicher!

test

EDIT: Meine Idee verwendet leider nicht die geforderte, sinnlose Fehler Klasse.
Du kannst die Idee aber leicht adaptieren indem du in der Map als Value die Fehlerklasse verwendest und die Methoden des Fehler Objekts aufrust.

Ich empfehle dir hier eine sinvollere Datenstruktur als eine ArrayList zu verwenden, nämlich eine Map (In anderen Sprachen Dictionary genannt).

Eine Map ist so etwas wie eine Arraylist, allerdings hat jede "Zeile" einen eindeutigen Schlüssel und ein dazu gespeichertes Objekt. Es ist also so etwas wie ein zweidimensionales Array in dem derselbe Wert nicht mehr als einmal in der ersten Spalte auftreten darf.
Map selbst ist lediglich ein Interface von dem du eine Implementierung verwenden musst.

Beispiel:

HashMap<String, Integer> map = new HashMap<String, Integer>;

Wobei links der String der Schlüssel ist, in deinem Fall also der Fehlername und rechts die Anzahl.
Hashmap braucht import java.util.* oder import java.util.HashMap

Zusatzinfo: Ebenfalls erlaubt ist es als Typ das Interface festzulegen:
Map map = new HashMap);

Die Hinzufüge Methode bei Maps heißt put(key, value). Falls schon vorhanden überschreibt put den Wert eines Schlüssels.

Die Methode add(String errorType, int amount) in der Klasse Registrierung schaut also etwas so aus:

if (!map.containsKey(errorType))
   map.put(errorType, amount);
else
  map.put(errorType, amount +map.get(errorType));

und getAmount(String errorType)

if(map.containsKey(errorType))
   return map.get(errorType);
else
   return 0;

Nach if und else Zeilen müssen keine Klammern folgen falls sie sich nur auf den Code bis zum nächsten ; beziehen.

test

01.11.2013, 21:10 Uhr - Editiert von Diabolo2000, alte Version: hier

Ebenfalls erlaubt ist es als Typ das Interface festzulegen:
Map map = new HashMap);

Erlaubt? Eine Klasse würde ich eher nur dann verwenden, wenn kein Interface existiert, das die konkrete Verwendung abdeckt (und mich gleichzeitig fragen, warum so ein Interface nicht existiert).

Nach if und else Zeilen müssen keine Klammern folgen falls sie sich nur auf
den Code bis zum nächsten ; beziehen.

Wenn das bei uns jemand versucht, kommt der Code nicht ins Repository...

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-142311.html#430

Jaja, die super duper Code Conventions, wo man nach 80 Zeichen einen Zeilenumbruch machen soll (wozu?!) oder wenn man 1000 Zeilen hat, sollte man die Klasse aufsplitten..
Genauso sollten Methoden nicht allzulange sein..

Manche CC machen ja einen Sinn, aber viele von den Java CC sind einfach nur

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

oder wenn man 1000 Zeilen hat, sollte man die Klasse aufsplitten..
Genauso sollten Methoden nicht allzulange sein..

Macht ja auch Sinn. Wenn eine Methode länger als eine Bildschirmseite ist (Pi mal Daumen, ist natürlich nur eine grobe Vorgabe), dann macht die Methode in 99% der Fälle zu viel. Das selbe gilt für ewig lange Klassen. Wenn mal eine Klasse über 1000 Zeilen hat, dann baut man in 99% der Fälle ein Big Hairy Object und sollte sein Vorhaben einmal ordentlich überdenken.

Ausnahmen bestätigen die Regel.

Von den 1000 Zeilen sind bei mir so im Durchschnitt 30-40% Kommentarzeilen und deswegen soll ich ne neue Klasse machen?
Dieses Theory Programming geht soweit an der Realität vorbei, das man kotzen möchte..

Und was hat eine Methodenlänge mit einer Bildschirmseite zum tun? Programmiert ihr alle in 80x25 Terminals?!?!
Vorallem da man in den IDEs ja auch die Schriftart ändern kann und ich seitdem ich Arbeit immer 2x20-24" Monitore habe..

So lasse ich mir noch einreden, wenn eine Klasse zuviel tut oder zu groß wird, das man es aufsplittet.. Sowas auf die Zeilenanzahl festzulegen ist aber Schwachsinn²³

Genauso das Methoden aufsplitten. Ich splitte Sachen auf die entweder logisch nicht mehr reinpassen oder öfters verwendet werden, aber wenn ich meine Methoden nach 25-40 Zeilen aufspalten sollte, dann ist das mehr zum Ärgern als Hilfe.
Vor allem, da ich viel kommentiere und das öfters gleich paar Zeilen sind - ja manchmal schreibe ich da auch die Geschäftslogik mit dazu ins Kommentar, damit man es leichter versteht..

Der nächste Unsinn in Java ist alles mit Interfaces zuzukleistern in kleinen Projekten oder wo man sowieso schon weiß, es gibt nur EINE Implementierung..
Ich habe so ein Projekt übernommen.. Da hat man >200 Interfaces und EINMAL gibt es 2 verschiedene Implementierungen. Der alte Dev was mir das gegeben hat, meinte selbst, dass sei über das Ziel geschossen und fürs weiterentwickeln oder debuggen ist es ein Zustand (vor allem, wenn es nicht von einem selbst ist!).

Also fix auf Zeilen/Spaltenanzahl zu gehen, wie es die Java CC eigentlich vorschreiben, halte ich für Bledsinn.

Zu große Klassen/Methoden sollte man aufsplitten, das ist klar!

Ist in den Java CC nicht auch noch, dass alle Klassen eigentlich "final" sein sollten und falls es jemand ableiten will, so soll man den Dev kontaktieren und dieser solle dann das final wegmachen

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Von den 1000 Zeilen sind bei mir so im Durchschnitt 30-40% Kommentarzeilen und
deswegen soll ich ne neue Klasse machen?

Zu 99% ja.

Es ist natürlich schwer eine harte Grenze zu definieren. Es ist ja nicht so, dass eine Klasse mit 999 Zeilen sinnvoll ist und eine mit 1001 Zeilen nicht mehr sinnvoll. Aber 1000 Zeilen sind selbst mit viel Kommentaranteil schon ziemlich viel und sollte zum Nachdenken anregen.

Und was hat eine Methodenlänge mit einer Bildschirmseite zum tun? Programmiert
ihr alle in 80x25 Terminals?!?!

Nein, aber je länger eine Methode ist, desto unübersichtlicher wird sie bzw. desto eher macht sie mehr als sie sollte.

Ein Stichwort, dass ich hier in den Raum werfen möchte, ist: Selbstdokumentierender Code. Je lesbarer der Code geschrieben wird, umso weniger Kommentare sind notwendig. Ein hoher Kommentaranteil kann auch ein Alarmsignal für unlesbaren Code sein. Das heißt aber nicht, dass ich dir das jetzt unterstellen möchte.

So lasse ich mir noch einreden, wenn eine Klasse zuviel tut oder zu groß wird, das man es aufsplittet.. Sowas auf die Zeilenanzahl festzulegen ist aber
Schwachsinn²³

Wie willst du es sonst messbar festlegen?

Genauso das Methoden aufsplitten. Ich splitte Sachen auf die entweder logisch
nicht mehr reinpassen oder öfters verwendet werden, aber wenn ich meine
Methoden nach 25-40 Zeilen aufspalten sollte, dann ist das mehr zum Ärgern als
Hilfe.
Vor allem, da ich viel kommentiere und das öfters gleich paar Zeilen sind - ja
manchmal schreibe ich da auch die Geschäftslogik mit dazu ins Kommentar, damit
man es leichter versteht..

Schreib die ausführlichen Kommentare über die Funktion und nicht in die Funktion.

Also fix auf Zeilen/Spaltenanzahl zu gehen, wie es die Java CC eigentlich
vorschreiben, halte ich für Bledsinn.

Ich sehe sowas als Empfehlung und nicht als eiserne Regel.

04.11.2013, 18:15 Uhr - Editiert von hellbringer, alte Version: hier

Nein, aber je länger eine Methode ist, desto unübersichtlicher wird sie bzw.
desto eher macht sie mehr als sie sollte.

Naja, ob jetzt durch zig Methoden durchhopsen muss, um endlich den Code zu finden der wirklich was tut oder ob lange Methoden was unübersichtlicher machen, liegt im Auge des Betrachters.
Wenn etwas von einem selber ist, versteht man sowieso alles viel besser als andere..

Auch bläht der Zeilenumbruch und lange Variablennamen alles extremst auf..
Ich habe manchmal Methoden aufrufe die gehen über 2-3 Zeilen, weil da Variablen alá "indexOfRemainingPages", etc. sind und eben nach 80 Zeichen umgebrochen wird.. (Code von Kollegen).
Sowas finde ich genau NULL übersichtlicher, eher noch das Gegenteil..

Ein hoher Kommentaranteil kann auch ein Alarmsignal für unlesbaren Code sein.
Das heißt aber nicht, dass ich dir das jetzt unterstellen möchte.

Manches kann man einfach und lange coden oder eben kurz und mehr Tricky und da sind Kommentare eben hilfreich..
Und ich habe Kollegen die sowas schreiben:

boolean var = true;

if(var)
return true;
else if(!var)
return false;

....

Wenn ich dann größere if-Konstrukte habe, dann kommentiere ich da eben auch die "ifs", bzw auch continue oder break in Schleifen (wobei ich die sowieso eher meide).

Wie willst du es sonst messbar festlegen?

Ein Plugin was dir nur Zeilen ohne Kommentar angibt

(und mehrzeilige Abstände)

Schreib die ausführlichen Kommentare über die Funktion und nicht in die
Funktion.

Sind natürlich im Header, aber öfters (bei ifs, zB oder schleifen) sind die nicht genug, bzw. braucht man auch woanders..
Und nein, das sind keine Kommentare alá: (würde zum obigen Beispiel passen)
//wenn variable true, dann gibt true zurück

Genauso finde ich eine { am Ende der Zeile oft als unübersichtlich..
zB hier gerade was offen gehabt:

if(arg0.getAnschriftcode().trim().equalsIgnoreCase(antrag.getEinschreiter().getCode())){
return this.ok();
}else{
return this.result(antrag.getEinschreiter().getCode());
}

Bei den ganzen Geklammere am Ende, hätte ich fast die { übersehen..

Man muss auch sagen, ich habe C/C++ gelernt (wegen { }) und kam erst in den letzten Jahren der HTL zu Java und wir haben das noch mit Notepad programmiert (JOE bekamen wir am Ende - das war purer Luxus!!).
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Naja, ob jetzt durch zig Methoden durchhopsen muss, um endlich den Code zu
finden der wirklich was tut oder ob lange Methoden was unübersichtlicher
machen, liegt im Auge des Betrachters.
Wenn etwas von einem selber ist, versteht man sowieso alles viel besser als
andere..

Es macht aber auch schon einen Unterschied, ob im Stack Trace grob ersichtlich ist, was passiert, als wenn man sich erstmal in eine 100 Zeilen-Funktion einlesen muss.

Auch bläht der Zeilenumbruch und lange Variablennamen alles extremst auf..
Ich habe manchmal Methoden aufrufe die gehen über 2-3 Zeilen, weil da
Variablen alá "indexOfRemainingPages", etc. sind und eben nach 80 Zeichen
umgebrochen wird.. (Code von Kollegen).
Sowas finde ich genau NULL übersichtlicher, eher noch das Gegenteil..

80 Zeichen sind heute einfach nicht mehr zeitgemäß. Üblicherweise einigt man sich auf einen Wert, der für alle Leute eines Projekts sinnvoll ist.

Manches kann man einfach und lange coden oder eben kurz und mehr Tricky und da
sind Kommentare eben hilfreich..
Und ich habe Kollegen die sowas schreiben:

boolean var = true;

if(var)
return true;
else if(!var)
return false;

....

Wenn ich dann größere if-Konstrukte habe, dann kommentiere ich da eben auch
die "ifs", bzw auch continue oder break in Schleifen (wobei ich die sowieso
eher meide).

Man kanns übertreiben, man kanns aber auch untertreiben. Ein "tricky" Code ist auf lange Sicht oft schwer wartbar. Besser ist es oft den längeren, aber verständlicheren Weg zu gehen.

Bei den ganzen Geklammere am Ende, hätte ich fast die { übersehen..

Wenn man sauber einrückt, kann man das eigentlich nicht übersehen. Außer man macht if-Blöcke, die über eine Bildschirmseite gehen, wo wir aber wieder beim Thema zu lange Funktionen wären

04.11.2013, 18:39 Uhr - Editiert von hellbringer, alte Version: hier

Es macht aber auch schon einen Unterschied, ob im Stack Trace grob ersichtlich
ist, was passiert, als wenn man sich erstmal in eine 100 Zeilen-Funktion
einlesen muss.

Das hängt von vielem ab.. Wenn ich zB eine NPE in einer Methode X habe, welche aber ein Objekt nutzt, was in Methode A gesetzt werden hätte müssen, dann kann man da auch lange suchen..

Einen perfekten Weg wird man da eher schwer finden. Der perfekte weg ist sowieso, keine Exceptions zu bekommen, bzw. die gewollten Abfangen und dann weiterarbeiten

Ein "tricky" Code ist auf lange Sicht oft schwer wartbar. Besser ist es oft
den längeren, aber verständlicheren Weg zu gehen.

Dann blicke nie in Frameworks

Wir nutzen viele Frameworks die so ziemlich gegen jede Firmen interne Conventions verstößt.. Aber hey, wenn es ein Framework macht, dann ist das scheinbar egal.

Vor allem finde ich es dann super, wenn ich mit Devs tratsche und diese Reflections komplett verbieten, aber dann iBatis & Co nutzen..
Auf die Frage wie iBatis die getter/setter von den Klassen aufruft, kommt dann meist keine Antwort oder die klassische "Naja, das ist ein JavaBean...".
Und da ich iBatis für uns verbessert habe, weiß ich das die Reflection nutzen, habe ja lange genug gesucht wo endlich die Klassen mit Werten versorgt werden (müssen ja auch für alles zig Interfaces einbauen, welche man aber nichtmal tauschen kann ohne den Source zu ändern - Logik?).

Wenn man sauber einrückt, kann man das eigentlich nicht übersehen. Außer man
macht if-Blöcke, die über eine Bildschirmseite gehen, wo wir aber wieder beim
Thema zu lange Funktionen wären

Tjo, ich habe 2 Projekte übernommen.. Das eine geht vor lauter Interfaces über und beim anderen wurde Java nicht vertraut (der hat sogar toUPPERCase nachgebaut und eben das lustige if Konstrukt von oben oder die gepostete Codezeile).

Zum Glück ist der vom 2ten Projekt schon in Pension, ansonsten hätte ich den Typen meinen Laptop schon paar mal um die Ohren geworfen.
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

boolean var = true;

if(var)
return true;
else if(!var)
return false;

test

Vorallem das else if ist der Hammer

Als könnte boolean (nicht verwechseln mit der Klasse Boolean) was anders außer true oder false sein

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Dieses Theory Programming geht soweit an der Realität vorbei, das man kotzen
möchte..

"Theory Programming" oder nicht doch etwa "Lessons Learned"? Empfehlungen von Programmierern, die jahrzentelange Erfahrung mit Projekten jenseits der Micky-Maus-Dimension haben, nehme ich jedenfalls dankend an (wie gesagt zur Evaluierung, und nicht dogmatisch).

Man muss ja nicht Wort für Wort nachbeten, aber es hat schon alles seine Daseinsberechtigung - auch der 80-Zeichen-Umbruch. Diese Empfehlung ist übrigens genauso wenig eine Eigenheit von Java Code Conventions wie dein zweites Beispiel.

Wenn das bei uns jemand versucht, kommt der Code nicht ins Repository...

Jede Firma hat ihre eigenen Regeln.
Bei uns bekommen zum Beispiel Spitzklammern stets ihre eigene Zeile.

test

Mit einer Arraylist gehts auch, siehe unten. Es ist aber nicht effizient, da man permanent über die Liste loopen muss. Die Variante mit einer Map wäre auch mein Vorschlag.

02.11.2013, 12:13 Uhr - Editiert von hihihi, alte Version: hier

das "...!fehler.contains(n)..." wird so nicht ganz funktionieren

Einfach das hinzufuegen des neuen Fehlers - wenn nicht schon vorhanden - unter die for-Schleife verschieben:

...
for(Fehler f: fehler){
....
}

fn.add(anzahl);
fehler.add(fn)

sg

das "...!fehler.contains(n)..." wird so nicht ganz funktionieren

Stimmt, wobei die Version in meinem Eclipse funktionieren sollte, da hatte ich in der Fehler-Klasse nämlich noch equals(Object o) und hashCode() implementiert/überschrieben. Ich hatte hier im Forum Problem, das geänderte Bild hochzuladen, es wurde einfach nicht aktualisiert. Daher ist wohl dummerweise die falsche Version online

wenn der tutor im 1. semester ein equals/hashcode override sieht, sollte er eigentlich eh fragen von wo derjenige dann abgeschrieben hast

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung