OOP - Telefonbuch

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/oop_telefonbuch_112626/page_1 - zur Vollversion wechseln!

soundjunk schrieb am 21.04.2004 um 14:08

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 schrieb am 21.04.2004 um 14:09

ist das tbuch dynamisch oder statisch implementiert?

wenn ersteres kannst eh nur linear suchen.. sonst halt binär oda gleich am gscheitesten interpoliert .

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.

soundjunk schrieb am 21.04.2004 um 14:11

dynamisch isses

und wie schreib ich jetzt die funktion?
und wie kann ich einträge alphabetisch sortieren?

thx

T3XT4 schrieb am 21.04.2004 um 14:12

Such halt im net nach Sortieralgorithmen.

Gibt eh genug..

Mein Liebling is ja da Bubblesort, wenns um nix geht

soundjunk schrieb am 21.04.2004 um 14:14

stimmt :P
an des hab i wida net dacht...

thx

Hatzki schrieb am 21.04.2004 um 18:58

Bubblesort 0wnt bad ass!

Da werden wieder Erinnerungen wach! MAH!

scnr

atrox schrieb am 21.04.2004 um 20:02

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 schrieb am 21.04.2004 um 20:27

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 schrieb am 22.04.2004 um 20:40

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 schrieb am 22.04.2004 um 22:02

Zitat von mkdigital
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

Code:

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 schrieb am 22.04.2004 um 22:09

in einem telefonbuch den namen als key zu nehmen sorgt vermutlich fuer eine automatische negative note

mkdigital schrieb am 25.04.2004 um 10:39

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 schrieb am 25.04.2004 um 12:03

Zitat von funka
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 :rolleyes:

atrox schrieb am 25.04.2004 um 12:16

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 schrieb am 26.04.2004 um 13:42

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.