basisklassendesign so in ordnung?



  • Ich hab alles in Kommentarform dazu geschrieben, was mir momentan Kopfzerbrechen bereitet:

    #include<windows.h>
    
    // Eine
    #define CFPP CurrentFilePointerPosition
    #define CRPP CurrentRecordPointerPosition
    #define MISSING_FIELDS
    #define FULL_RECORDS
    #define TRANSLATION_REQUIRED
    
    // Basisklasse, soll eines Tages (bis in zwei Wochen)
    // die Aus- und Eingabe sowie die Abfrage von Records
    // im berüchtigten FileWizard Format ermöglichen, bei
    // bisher immer noch nicht bekanntem UI
    
    class FileWizard{
    	HANDLE FileOfInterest;
    	ULONG FileSize;
    	static ULONG CurrentFilePointerPosition;
    
    	USHORT* LinkedField;
    	USHORT NumberOfUnlinkedFields;
    
    	ULONG NumberOfRecords;
    	static ULONG CurrentRecordPointerPosition;
    
    	static LPSTR placeholder;
    
    	UCHAR FieldSeparator;
    	UCHAR RecordSeparator;
    
    	HANDLE* MappedFields;
    	ULONG NumberOfMappedFields;
    
    	HANDLE* MappedRecord;
    
    public:
    	FileWizard(LPSTR FileName);
    	void SetFieldSeparator(UCHAR NewFieldSeparator);
    	void SetRecordSeparator(UCHAR NewRecordSeparator);
    	void SetLinkedField(USHORT LField);
    
    	virtual bool DynSetFieldUI(HANDLE* Targets);
    	virtual bool DynSetRecordUI(HANDLE* Targets);
    
    	virtual bool FindRecord();
    	virtual bool SaveRecord();
    	virtual bool DeleteRecord();
    	virtual bool ClearResults();
    	virtual bool CreateLink(USHORT NewLinkedField, ULONG TargetRecord);
    };
    
    // Jeder darf mithelfen.
    // Zur Erklärung:
    // FileWizard-Format ist eine Art äußerst kompaktes Datenspeicher-
    // format,
    // das ohne Angaben zu Feldgrößen auskommen soll, und also beispiels-
    // weise nicht 85 Byte wegschmeißt, wenn eine Feldgröße mit 90
    // definiert wurde und dann nur 5 Byte den Weg in das Feld gefunden
    // haben. Es ist zu erwarten, dass 66% aller zu erwartenden Ein-
    // träge in diesem Feld zwischen 50 und 75 Zeichen lang sein werden,
    // und deshalb ist mir die Idee mit den Trennzeichen zwischen den
    // Feldern und den Records eingefallen, die zwar pro Feld ein 
    // Extrabyte kosten, aber sagen wir bei 100.000 Einträgen oder mehr 
    // doch zu deutlich kompakteren Dateien führen.
    // LinkedField ist natürlich eine Variante eines Schlüsselfelds, das
    // bei diesem chaotischen (weil kompakten) Speicherformat trotzdem noch
    // Abfragen durch Verweis auf mit dem Record, in dem es steht,
    // verknüpfte Records, beschleunigen helfen soll.
    // Wirklich schlimm ist nur, dass noch nicht vorhersehbar ist,
    // WO die Datei eigentlich dann herkommen soll, und wie das User
    // Interface dann aussehen wird.
    
    // Findet Ihr, ich bin mit der Basisklasse da für alle Überraschungen
    // gerüstet, oder ist die zu unflexibel? Jedenfalls Danke für Verbesserungs-
    // vorschläge.
    


  • Trollbeitrag!!

    Bitte schließen.



  • Mecnels schrieb:

    FileWizard(LPSTR FileName);
    

    Wenn du im Konstruktor eine Datei öffnest, dann wäre ein Destruktor in dem du sie wieder schließt IMHO ne tolle Sache.



  • Virtuelle Methoden, aber kein virtueller Destruktor. Eher gar keiner wie Mastah schon sagte ⚠

    Ich würde ein dateibasiertes Datenbanksystem eh bissle anders angehen. Wieso nicht eine Index-File, wo du Positionen loggst?

    Die brauchst du imho zwangsläufig, da du die Verschiebungen innerhalb der Datenfile minimieren musst.

    Diese Index-File enthält Positionen der Datensätze etc und wird selbstverständlich ständig aktualisiert. Dann brauchst du auch keine Trennzeichen.

    Denk mal drüber nach pls.

    edit: Wenn du gar von einer ungefähren Datenlänge ausgehst bleibst du pervers unflexibel ;).



  • Wer hat verstanden was die Klasse soll? Ich nicht.



  • ich nicht schrieb:

    Wer hat verstanden was die Klasse soll? Ich nicht.

    Wenn man von unzähligen Datenbanksystemen und auch kleineren Lösungen (SQLite und Konsorten) ausgeht ergibt das wirklich keinen Sinn 🤡



  • simon.phoenix schrieb:

    ich nicht schrieb:

    Wer hat verstanden was die Klasse soll? Ich nicht.

    Wenn man von unzähligen Datenbanksystemen und auch kleineren Lösungen (SQLite und Konsorten) ausgeht ergibt das wirklich keinen Sinn 🤡

    Danke soweit, das mit der extra Index File macht Sinn (Ich war mir auch nicht sicher, ob ich die File im Konstruktor oder einer separaten Init() Funktion öffnen sollte.)

    Ihr kennt Euch ja gut beim Modularisieren aus, findet ihr, die Klasse vertrüge noch ein paar Extramethoden?



  • Alter...fang doch einfach an...und dann merkst du schon wo es Probleme gibt.


  • Mod

    ich verstehe auch nicht, was die klasse tun soll. soll sie zugriffe auf eine (relationale) datenbank in zugriffe auf eine datei übersetzen? dann möchtest du vielleicht lieber einen proxied container bauen. für den nutzer ist es doch völlig unerheblich, wie diese übersetzung geschieht. insofern finde ich irgendwelche verweise auf eine ui irritierend. im übrigen handelt es sich hier eindeutig um windows-code, möglicherweise ist der thread also besser im mfc/vc forum aufgehoben.

    HANDLE FileOfInterest;
        ULONG FileSize;
        static ULONG CurrentFilePointerPosition;
    

    wieso ist CurrentFilePointerPosition (ist das nicht doppelt gemoppelt?) static, wenn FileOfInterest und FileSize es nicht sind?



  • Sieht mir so aus als wenn er das static Schlüsselwort zufällig verteilt hat.



  • Ich verstehe auch nicht, was die Klasse macht. Also lese ich mal die Dokumentation zur Klasse.
    [cpp]// Basisklasse, soll eines Tages (bis in zwei Wochen)
    // die Aus- und Eingabe sowie die Abfrage von Records (was für Records? worum geht es überhaupt?)
    // im berüchtigten FileWizard Format ermöglichen, bei
    // bisher immer noch nicht bekanntem UI[/cpp]Was ich unterstrichen habe, ist IMHO schlicht unnötig, was kursiv ist, kann ich nicht in einen eindeutigen Zusammenhang setzen. Was übrig bleibt ist irgendwas mit I/O und das reicht mir nicht, um die Schnittstelle bewerten zu können.



  • sras schrieb:

    Sieht mir so aus als wenn er das static Schlüsselwort zufällig verteilt hat.

    Sollte ja ursprünglich nur ein Zweiergespann (Anwendungsobjekt) + (Datei) werden, deshalb. Aber mit Euren Tipps hier hat sich das ja geändert.
    Besten Dank jedenfalls.



  • Mecnels schrieb:

    findet ihr, die Klasse vertrüge noch ein paar Extramethoden?

    Keine Ahnung, es gibt zuwenig Doku um das zu wissen.

    Aber sie würde ein paar andere Members vertragen.

    zB hast du mal klar eine Klasse File um die Zugriffe auf die Datei und die Datei selber zu wrappen.

    Das mit dem Separator ist irgendwie unflexibel, weil du damit die Daten limitierst die du Speichern kannst. (nämlich nur Daten, wo der Separator nicht vorkommt).

    Weiters ist mir viel zuwenig klar, deshalb kann man im Prinzip nur raten..


Anmelden zum Antworten