OOP - Telefonbuch
soundjunk 21.04.2004 - 14:08 1104 14
soundjunk
Bloody Newbie
|
Hi, ich habe ein Projekt in der Schule laufen. Die Aufgabe besteht darin ein objektorientiertes Telefonbuch zu erstellen. So weit so gut und kein Problem.
Nur haben wir keine Ahnung wie wir eine Suchfunktion für dieses Telefonbuch schreiben sollen...
Ideen? Skripte?
tia
soundjunk
|
T3XT4
Beißer
|
ist das tbuch dynamisch oder statisch implementiert? wenn ersteres kannst eh nur linear suchen.. sonst halt binär oda gleich am gscheitesten interpoliert ![;)](/images/smilies/wink.gif) . edit: Naja, da es aber wahrscheinlich nicht sortiert sein wird musst so oder so linear suchen... Wenn man nur in einem Ort sucht, würds anders auch gehen.
Bearbeitet von T3XT4 am 21.04.2004, 14:11
|
soundjunk
Bloody Newbie
|
dynamisch isses
und wie schreib ich jetzt die funktion? und wie kann ich einträge alphabetisch sortieren?
thx
|
T3XT4
Beißer
|
Such halt im net nach Sortieralgorithmen. Gibt eh genug.. Mein Liebling is ja da Bubblesort, wenns um nix geht
|
soundjunk
Bloody Newbie
|
stimmt :P an des hab i wida net dacht...
thx
|
Hatzki
Pinky in action
|
Bubblesort 0wnt bad ass! ![:)](/images/smilies/smile.gif) Da werden wieder Erinnerungen wach! MAH! ![:D](/images/smilies/biggrin.gif) scnr
|
atrox
in fairy dust... I trust!
|
alle besseren-als-linearer-aufwand suchalgorithmen benötigen in irgendeinerweise speziell angeordnete/sortierte datenstruktur.
dh aber auch, daß du für zusätzliche suchfelder - wie zb strassennamen oder vornamen - zusätzliche datenstrukturen/indezes brauchen wirst, wenn du sublinearen aufwand haben möchtest.
und: bubblesort ist gut als model, ab einigen hundert datensätzen siehst du ziemlich dumm drein. (O(n²))
|
that
Hoffnungsloser Optimist
|
Bubblesort ist so ziemlich der dümmste Sortieralgorithmus, den man überhaupt programmieren kann. Insertion Sort ist einfacher und schneller, vor allem wenn nur neue Einträge zu einer sortierten Liste dazukommen.
Abgesehen davon bietet doch heutzutage eh schon jede OO-Sprache irgendwelche fertigen Collections an, da muss man nicht das Rad neu erfinden.
|
mkdigital
Big d00d
|
wenn du von schule und OOP redest, und schüler bist, nehm ich an du codest in JAVA? wenn ja: schau dir mal das java.util package an. da gibts fix und fertige sortieralgorithmen. zB; sortet tree: da kannst due key/value pairs reinspeichern, und er sortierst automatisch, wenn du die compareto funktion korrect überlagert hast. und des is glei gmacht public int compareTo(String t){ return t.compareTo(this.whatever); }
mfg
|
gue
Addicted
|
wenn du von schule und OOP redest, und schüler bist, nehm ich an du codest in JAVA? wenn ja: schau dir mal das java.util package an. da gibts fix und fertige sortieralgorithmen. zB; sortet tree: da kannst due key/value pairs reinspeichern, und er sortierst automatisch, wenn du die compareto funktion korrect überlagert hast. und des is glei gmacht public int compareTo(String t){ return t.compareTo(this.whatever); }
mfg Ich glaube, du meinst die Klasse java.util.TreeMap. Wenn er da aber seine Telefonbuchinstanzen hinzufügt und als Schlüssel z.B. den Namen benutzt (ich gehe mal davon aus, dass der Name mit einem String gespeichert wird), dann braucht er compareTo nicht implementieren, da das schon in String gemacht wurde. Übrigens heißt es compareTo(Object o). @soundjunk: Wenn du das in der Schule machst, reicht es wohl, ein Array anzulegen mit deinen Telefonbuchinstanzen und das einfach liniar zu iterieren, also static TelephoneBookEntry searchForName(TelephoneBookEntry[] telbook, String searchstring) {
for (int i=0; i < telbook.length; i++) {
if (telbook[i].name.equalsIgnoreCase(searchstring)) {
return telbook[i];
}
}
}
Es sei denn, euer Lehrer verlangt da mehr von euch und eine garantierte O(log n) Laufzeitkomplexität für Einfüge- und Auslese-Operationen aber wenn euer Lehrer so ist wie meine waren, dann weiß er nicht mal, was das ist
|
funka
Legend ex-prophet(down below)
|
in einem telefonbuch den namen als key zu nehmen sorgt vermutlich fuer eine automatische negative note
|
mkdigital
Big d00d
|
man kann ja auch einen zusammengesetzten schlüssel nehmen. ich wollt damit nur sagen dass die sortierart nur von der overridden funktion abhängt. nimm hald name+geburtsdatum oder was weis ich...
mfg
|
gue
Addicted
|
in einem telefonbuch den namen als key zu nehmen sorgt vermutlich fuer eine automatische negative note Ich weiß ja nicht, wonach du normalerweise in einem Telefonbuch suchst; ich such meistens nach einem Namen
|
atrox
in fairy dust... I trust!
|
verwechselt jetzt nicht den (primary und damit unique) key mit dem feld, nachdem gesucht/sortiert wird.
wenn auch im echten leben, eher undenkbar, wäre es möglich, daß bei dem übungsbeispiel gar kein PK vorkommt/benötigt wird.
|
Obermotz
Fünfzylindernazi
|
Hmm, die EDV-HTLs (ich denke mal, du besuchst so eine), behandeln OOP besonders im Zusammenhang mit der Sprache C++. Darum kommt Java wahrscheinlich nicht in Frage.
Nachdem das Projekt wahrscheinlich nicht in der Praxis angewandt werden wird empfehle ich einen Selection- oder Insertionsort (Laufzeit --> Relativ egal). Möglich wäre (wenn dir fad ist) auch ein Quicksort.
|