Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
1. Aug 2015
Wenn die Cache-Klasse auch das Schreiben besorgt, muss die Anwendung zu speichernde Daten nur an einer Stelle "abgeben", sonst muss sie die Daten sowohl in den Cache schreiben als auch selbst auf das externe Medium speichern.
Mir erscheint eine Klasse, die transparent den Zugriff auf die Daten organisiert und dabei die Daten cached, wesentlich zweckmässiger als eine reine Cache-Klasse, in der...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
1. Aug 2015
Ich spreche von meinem Algorithmus.
Du hast einen einfachen MRU (laut inzwischen modifizierter Vorgabe, im Eingangspost war etwas anderes verlangt) implementiert, da braucht man das natürlich nicht.
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
1. Aug 2015
Hier mein erster Versuch.
Das Interface der Klasse habe ich bewusst etwas anders gestaltet als in der Vorgabe: Die Klasse kümmert sich sowohl umd das Nachladen von Objekten aus dem externen Speicher als auch um das externe Speichern veränderter Daten.
Dazu müssen ihr beim Create zwei Routinen übergeben werden, die das Laden und Speichern der Daten erledigen. Das Programm, das den Cache dann...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
31. Jul 2015
Natürlich. Im Optimalfall sollte eine Strategie an die typischen Szenarien der konkreten Anwendung angepaßt sein. Im Prinzip geht es um die zwei Kriterien "most recently used" und "most frequently used". Die Strategie, die ich vorgeschlagen habe, ermöglicht es, die beiden Kriterien anwendungsspezifisch auszubalancieren.
Nachdem wahrscheinlich meistens das erste der beiden Kriterien das...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
31. Jul 2015
Uwe Raabe hat Recht. Deine Vorgabe verlangt, dass die Häufigkeit der Zugriffe berücksichtigt wird, in deinem Ansatz geht es nur darum, auf welches Element am längsten nicht zugegriffen worden ist, auch wenn davor die Zugriffe sehr häufig waren.
Eben nicht. Sie enthält vorne die Elemente, die vor kurzem abgefragt wurden. Was in der Tendenz öfter war, darüber speicherst du keinerlei...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
31. Jul 2015
Uwe Raabe hat es richtig geschrieben. Es fehlt in deiner Vorgabe eine zeitliche Komponente, ohne die wird keine gute Performance herauskommen (und dein eigener Lösungsansatz ignoriert deine Vorgabe übrigens komplett, der implementiert NUR die zeitliche Komponente).
Das Problem dabei: Wenn ab irgendeinem Zeitpunkt ein anderes (ganz neues) Element als die bisher häufigsten öfter gebraucht wird,...
Forum: Algorithmen, Datenstrukturen und Klassendesign
by idefix2,
30. Jul 2015
Ja, das sehe ich auch so.
Beim Zugriff auf ein Element, das nicht im Cache ist, sollte das Nachladen meines Erachtens durch die Klasse selbst erledigt werden - z.B. durch eine Callback-Routine, die beim Create übergeben wird.