OOP - Telefonbuch

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.

Such halt im net nach Sortieralgorithmen.

Gibt eh genug..

Mein Liebling is ja da Bubblesort, wenns um nix geht

Bubblesort 0wnt bad ass!

Da werden wieder Erinnerungen wach! MAH!

scnr

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.

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

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

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.