[Wiesel]

15 Tag war Pause im Smalltalk, das nenne ich mal eine Errungenschaft :-D

[Holger_N]

Zitat (RalphS: 23. April 2017 - 17:33)

…
Bin aber auch nicht der Stylie. Hauptsache es funzt, wurstpiepe wie es aussieht.
…

Ja das Design wird oft überbewertet und wenn es dann auch noch über technische Unzulänglichkeiten hinwegtäuscht, im Sinne von »Hauptsache schön verpackt, aber funktioniert nicht so richtig« dann regt mich das auch auf, aber son bißchen Struktur hab ich schon gerne drin und so kann man jetzt schön ein Gestaltungsraster anlegen, ohne mit 100 DIVs rumzufrickeln.

Noch ist es aber wohl zu früh. Scheinen nur die allerneuesten Browser zu können.

[RalphS]

Sicher, sicher. Und ich bin absolut für eine logische Trennung von Code und Gestaltung.

Nur, auf der anderen Seite sind so halt Websites ohne CSS nicht mehr zu gebrauchen. CSS kaputt? Server mit den CSS-Daten kaputt? Oder der Browser kann das einfach nur nicht? ... Pech gehabt. Und wie das mit serialisiertem Lesen aussehen soll, also für Braillezeilen oä, ... da denk ich lieber nicht drüber nach. Mit HTML+CSS gibt es ja kein 'Nacheinander' mehr, da kann ja jedes Objekt in der HTML-Datei sonstwo sonstwie definiert sein, und CSS schiebt das dann schon.

Wenn ich nicht so faul wäre tät ich mir mal XSLT genauer anschauen. Das hat aber dann auch wieder den Nachteil, daß man zwar ein ordentliches Ergebnis kriegt (wenn man es richtig macht) aber dafür ist XSLT im Gegensatz zu CSS eher undurchsichtig.

[Holger_N]

Ich glaube jetzt habe ich nach nach mehreren Anläufen endlich C++ verstanden, also zumindest das wie das funktioniert und das nur durch Zufall. Ich hatte es aufgegeben und wollte mal gucken wie das mit Python so funktioniert, bin dann über die Entwicklungsumgebungssuche zu Qt gekommen, und darüber wieder zurück zu C++. Vorher hatte ich auch schon mit Visual Studio rumprobiert aber alle diese Baukästen haben ja zum Teil gar nicht so viel mit richtigem C++ zu tun und deshalb funktionieren auch diese ganzen Tutorials mit den Beispielen immer nie. So und zum Programme zusammenkloppen werde ich mich weiter in Qt einarbeiten und zum richtigen C++ lernen kann dat Dingen auch reine C++ Projekte ohne Qt. Mal gucken, wie lange das gut geht. Noch ist der Spaß da. Obwohl die ersten Probleme schon da sind. Einfach mal dem Programm bescheidsagen, dass ne DLL im Unterordner liegt ist schon eine Herausforderung.

Dieser Beitrag wurde von Holger_N bearbeitet: 01. Mai 2017 - 19:44

[Holger_N]

Macht immernoch Spaß und wird auch immer durchsichtiger der Fall. Werd mir mal als Nächstes einen theoretischen Überblick über die Datentypen machen. Da kann man sich Daten aus einer Textdatei auslesen, 5 funktionieren, die 6. nicht. Schon seltsam.



Soo - eine Woche rum und noch immer voller Begeisterung. Das wird ein schönes kleines Progrämmchen.

Dieser Beitrag wurde von Holger_N bearbeitet: 08. Mai 2017 - 14:49

[Holger_N]

Fertich - also soweit fertich. Da werden bestimmt noch Fehler auftauchen oder mir fällt noch was ein, was man verbessern oder erweitern könnte aber von dem was ich ursprünglich wollte, geht schonmal alles.

[RalphS]

Sieht doch ganz nett aus.

Wo landen denn die eingegebenen Daten? Im Arbeitsspeicher (nach Programmende weg) oder irgendwo anders?

Ich bin grad dabei, eine meiner Datenbanken bissel reparieren zu müssen. Irgendwas ist da bei einem UNIQUE Index schiefgegangen -keine Ahnung warum- und der Index war plötzlich gar nicht mehr unique. Also hatte ich ihn rausgeworfen... und das dann prompt vergessen.

Nicht viel später und es gab >30GB Daten in der Datenbank statt sowas wie 10-15. Aufräumen... eh. Selbst mit deaktivierter DB-Kommunikation und ohne Indices dauern die Löschvorgänge bissel. Der letzte läuft grad, nach Abschluß welches das wieder UNIQUE sein wird, sodaß der Index wieder rauf und die DB wieder aktiviert werden kann.

Aber die depperte Abfrage für die paar Millionen überzähligen Zeilen... läuft inzwischen seit über 48 Stunden. Ich glaub das mit dem Pentium ist fürs DBMS vielleicht doch ein bissel zu dünn.


In other news: Jena steht noch, auch wenn gestern irgendwie das bald abgesoffen wäre. Was fürn Wolkenbruch und das auch noch gefühlte Ewigkeiten.


Moin.

[Holger_N]

Man kann die Daten in eine Textdatei speichern. Hab ihr ein eigenes Format gegeben (.medat) ist aber nichts anderes als eine csv mit Semikolon als Separator und jede Zeile ein Datensatz für ein Medikament. Man kann also diverse Dateien für einzelne Patienten anlegen. Das Programm erzeugt einen eigenen Ordner in AppData/Roaming/[AppName] und da ist dann eine Leerdateidatei drin und die Sprachdateien (deutsch, englisch und eine personalisierte Version) und eine Hilfe-Datei, sowie eine ini, wo der Pfad zur letzten verwendeten Datei gespeichert ist. Mit dieser startet dann das Programm ab dem zweiten Start.
Die selbst angelegten Patienten-Dateien sind natürlich nicht in Roaming sondern können beliebig gespeichert werden, als default ist der »Dokumente« Ordner des Benutzers voreingestellt.

Die personalisierte Sprachdatei ist die englische Datei kopiert (auch ne ini) nur leicht verändert, dass man sie erkennt und da könnte man wenn man wollte und die Sprache kann, sich zum Beispiel eine französische Version schreiben. Also alles was an Labeln und Beschriftungen im Programm vorkommt steht in Variablen, die aus den Sprachdateien ausgelesen werden.

Ich will das ganze aber auch nochmal mit einer Datenbankdatei umsetzen. Mal sehen, was sich da anbietet. In nem alten VB 6 Programm (Bundesligatippspiel) hatte ich das mal mit ner Access-Datei gemacht. Mal gucken, das wäre für den Programmumfang zwar ein bißchen überdimeinsioniert, weil die csv ja eigentlich alles macht, was sie soll, aber die Datenbank würde einiges an zusätzlichen Berechnungen und Abfragen bieten, die dann viel einfacher umzusetzen sind. Vor allem auch wenn man mehrere Patienten zugleich »überwachen« will.

Hab auch schon eine kleine »Anleitung« zu gebastelt.

 MediPlaner_Anleitung.pdf (411,62K)
Anzahl der Downloads: 169


Also das Programm an sich ist schon ganz gut und genau auf meinem Bedarf zugeschnitten. Ich bin beim Arzt und dann kommt die Frage »Brauchst Du Medikamente?« und dann weiß ich den Stand nicht aus dem Kopf oder ich weiß ihn und kann sagen welche Medikamente in 4 Wochen alle sind, aber der Arzt sagt, wegen Urlaub etc. wäre der nächste Termin erst in 6 Wochen, dann weiß ich wieder nicht den Stand. So druck ich mir den Plan aus – kann das Programm alles – und bein beim Arzt auf dem laufenden und kann sagen entweder die nötigen Rezepte mitnehmen oder entscheiden, dass es besser ist, vor dem Urlaub nochmal vorbeizukommen.

Der einzige Nachteil den ich sehe ist, dass in der allgemeinen Menge kein allzu großer Bedarf da ist. Meine größte Freude ist aber wie gesagt, dass es genau so geworden ist, wie es am Anfang geplant war. Das ist bei meinen Projekten nicht oft so. Und dann war es natürlich eine feste vorgegebene Problemstellung, die ich lösen mußte, was beim lernen mehr Sinn macht, als Code aus einem Buch, wo am Ende irgendwas ohne Sinn blinkt.

Dieser Beitrag wurde von Holger_N bearbeitet: 20. Mai 2017 - 16:55

[Holger_N]

Ich sage ja immer, dass ich die objektorientierte Programmierung nicht verstehe, aber langsam glaube ich dass ich das unbewußt sehr wohl praktiziere und ich nur den Begriff nicht zuordnen kann, was an dem ganzen Ding nun objektorientiert ist. So wie jemand, der den ganzen Tag Auto fährt und nicht weiß, dass dann Ding was er fährt Auto heißt und deshalb die Frage, ob er Auto fahren kann verneint.

[RalphS]

Ja, das Gefühl, was selber auf die Beine gestellt zu haben... und vor allem so, wie man es haben wollte.

Ob das jetzt objektorientiert ist was Du da verzapft hast oder nicht, naja spielt das eine Rolle, wenn man das nur für sich selber macht? Solange wie das richtige rauskommt, ist es doch gut.

Im OO-Ansatz hättest Du vermutlich eine Objektklasse Medizin, mit oder ohne spezifischen abgeleiteten Klassen. Weil, "Medizin" ist ja nix Greifbares. Aber Tabletten sind es, also könnte es eine aus Medizin abgeleitete Klasse namens Tablette geben. Medizin hätte dann allgemeine Eigenschaften -zB Wirkstoff, weil jede Medizin einen hat oder zumindest haben sollte. Packungsgröße wäre zu fragen. Aber Tabletten kann man nicht in Milliliter angeben, also ist das keine Medizin-Eigenschaft, sondern eine Tablette-Eigenschaft und man braucht noch eine zweite aus Medizin abgeleitete Klasse namens Heiltrank oder sonstwas. Die kann dann eine Größenangabe in Milliliter haben.

Und so weiter, und so weiter, und so weiter. Der Vorteil von Objektorientiert ist, daß man sich buchstäblich nur das reale Leben angucken muß und wissen muß, was man für seine Aufgabe(n) braucht. Die Zuordnung ist dann vergleichsweise einfach.

Das geht dann sogar soweit, daß man zB eine Klasse Medizinschrank haben kann, die Eigenschaften wie PlatzFürMedikamente hat, welche selbst wieder Objekte sind und so Medizinschrank.PlatzFürMedikamente.Pillendose verfügbar wird. (Oder andersrum, je nach Laune; also Medizinschrank.Pillendose.VerbleibenderPlatz. Dann kann man nämlich gucken, wieviel da ist, und wieviel in den Schrank noch reinpaßt.

[Holger_N]

Was mich jetzt noch bewegt, ist die Frage nach Speicher Leaks und dergleichen. Ich habe da ein paar Programme probiert, die das auswerten und da habe ich Ergebnisse, die sind alle ganz toll aber ich kann die nicht auswerten. Ich weiß nicht, was gut und was schlecht ist.

[Holger_N]

Aber gut, jetzt bin ich mir schon wieder sicher, die Objektorientierung nicht verstanden zu haben. Für mich ist eine Klasse nur eine Funktion, die ohne erkennbaren Grund in ein zusätzliches Klammernpaar gesteckt wurde. In php mache ich das, weil die Klassen sich so schön per autoload einbinden lassen. Für die eigentliche Abarbeitung hätte aber die Funktion auch gereicht.

Edit meint: Je länger ich darüber nachdenke, umso verständlicher werden die Klassendinger gerade. Das muss ich nachher unbedingt mal ausprobieren. Ich hatte in Büchern bislang nur immer so Waschmaschinenbeispiele gefunden, die ich praktisch schon nicht verstand.

Dieser Beitrag wurde von Holger_N bearbeitet: 21. Mai 2017 - 08:25

[RalphS]

Es gibt formale und informelle 'Definitionen' für objektorientierte Programmierung - ich denke, wenn man das nebenher macht, dann braucht man die formalen Definitionen nicht. Wenn ich jetzt mit Begriffen wie Polymorphie und Kapselung und Zugriffslevels komme, dann hast da überhaupt nix von. Entsprechend muß man auch ein bissel schauen, daß man was nach Art von "Object Orientated Programming: For Dummies" findet.

Objektmodellentwicklung ist aber mehr oder weniger dasselbe wie Datenbankmodellentwicklung (nicht 100%ig identisch, aber sehr ähnlich). Man muß sich halt überlegen, was wozu gehört und über DB-Modellierung hinaus was wie womit zusammenhängt.

Für OO kommt dann noch die Objektinstantiierung hinzu: Ich habe also meine Klasse Medizin, und ich habe auch meine Klasse Tablette, aber wie krieg ich jetzt eine konkrete Pillendose (= Instanz) beschrieben? Was brauche ich dafür? Dafür sind Konstruktoren gut und hier hilft die -sogenannte- Polymorphie.

Nach bissel Überlegen kommt also raus, ich hab ein Standardpillendosenformat. Dann kann ich sagen

Pillendose p = new Pillendose();

. Dann habe ich eine leere Pillendose oder, wenn die Klasse Pillendose bereits eine Größe definiert, vielleicht auch eine volle. Aber es soll ja auch halbvolle Pillendosen geben und dann will ich sagen können

Pillendose p = new Pillendose(20);

. Oooooder ich will eine Pillendose anhand einer Standardisierung erstellen, sagen wir N1 oder N2 oder N3. Dann muß ich mir zuerst überlegen, ob die einzelnen Formate eigene Eigenschaften haben sollen oder nicht. Falls ja, brauche ich einen Objekttyp dafür. Falls nicht, reicht eine Konstante. Die kann ein String sein ("N1"), aber ich kann genausogut eine Klasse von "String" ableiten, was den Vorteil hat, daß ich

Pillendose p = new Pillendose((Dosenformat) "N1")

sagen kann, aber nicht

Pillendose("N1")

oder gar

Pillendose((Dosenformat) "A4")

weil das schlicht nicht definiert ist.

Oder kürzer formuliert, objektorientiert kann man das alles sehr streng gestalten mit dem Ziel, Fehleingaben und Fehler bei der Programmierung von Grund auf zu vermeiden. Ja, dann kriegt man Fehlermeldungen. Aber die Alternative wäre, daß man dann aus Versehen eine Pillendose in der Größe "N" in der Datenbank hat, wo man dann später nicht weiß, was man gemeint hatte.


Anyway, der Punkt ist der: Mit OO geht sowas parallel. Man kann Funktionen haben, die gleich heißen (hier: der Konstruktor) die aber völlig verschieden spezifizierbar sind. Die Anwendung sucht sich dann die Funktion aus anhand der übergebenen Parametertypen. Und so kann man Auskippen() haben für alles und gleichzeitig auch Auskippen(5) für "fünf Pillen auskippen" und zur selben Zeit aber eben auch Auskippen(.5) für "die Hälfte der Pillen auskippen" oder sonstwas anderes. Aber man hat am Ende eine Funktion, auf die man zugreifen kann, und die heißt Auskippen und tut, was man erwartet. Nicht AllesAuskippen() und nicht EinPaarAuskippen() und auch nicht AnteiligAuskippen().

Dieser Beitrag wurde von RalphS bearbeitet: 21. Mai 2017 - 09:46

[Holger_N]

Ja das ist das ja. Wenn ich eine Pillendose habe und da sind 30 Stück drin und ich nehme 3 raus, dann habe ich doch mit 30-3 schon mein fertiges Ergebnis. Da kann man schlecht erklären, warum es besser ist 12 Kilometer Text zu tippen mit allerhand Variablen und Zeigern und Sternchen, um dann am Ende auch nur auf 3 zu kommen. Das ist wie gesagt auch das Problem in den For-Dummies-Büchern. Ich mag die Buchreihe ja und für VB6 hatte ich mir das damals auch geholt, aber da sind dann diese Beispiele, wo man den Sinn nicht richtig erkennt. Der Fehler liegt ja wahrscheinlich bei mir, dass ich in dem Moment noch nicht abstrakt genug denken kann.

Ich werde als Erstes mal versuchen, mir so eine Medikamentenschachtel als Objekt zu bauen. Vielleicht komme ich dann dahinter. Müßte mir nur erstmal einfallen, an welcher Stelle im Programm das rein muß. Ich hab so eine schöne Variable oder einen mehrdimensionalen Vector, da gibts ja in jedem Tutorial andere Bezeichnungen für, medizin[x][y] wo x für das Medikament steht und y um welchen Wert es sich handelt und mir fällt nicht ein, mit was für einer Klasse man dieses Prinzip verbessern könnte. Das Auslesen wird komplizierter, das Verarbeiten wird komplizierter und das Speichern wird komplizierter. Na egal, mal versuchen.

Dieser Beitrag wurde von Holger_N bearbeitet: 21. Mai 2017 - 15:30

[RalphS]

Und genau sowas sollte eigentlich nicht notwendig sein.

Das ist eine Definition für eine Klasse. Die hat zumindest normalerweise nicht mehrere Dimensionen, die man in eine einzelne Variable stopfen müßte.

Was macht denn so ne Schachtel?

- Sie beinhaltet eine Anzahl Tabletten. Also eine numerische Variable. Vermutlich, aber nicht notwendigerweise, als Integer (Ganzzahl) je nachdem ob auch halbe Tabletten drin sein können, weil man die halt nur anteilig rausnehmen kann. In dem Fall wäre eine Fixkommazahl die einzig brauchbare Option.

- Dann müssen wir uns fragen, ob dieser Füllstand nach außen kommuniziert werden muß. "Normal" sieht man das bei einer Pillenpackung nicht, es liegt also nahe, den Füllstand auch zu verbergen (optional; muß man nicht tun).

- Nächste Frage ist, ob der Füllstand eine Klasseneigenschaft ist (alle Objekte dieser Klasse haben denselben Wert) oder nicht (Objekte haben individuelle Werte). Offensichtlich kann jede Pillenschachtel unterschiedlich voll sein. Deswegen gibt es KEIN static-Schlüsselwort.

- Da der Füllstand privat ist (oder sein kann) kann man also von außen nicht drauf zugreifen. Der Füllstand muß aber irgendwie Sinn ergeben. Wie ändern wir also den Füllstand?
Zwei Wege: (A) Pillen reintun; (B) Pillen rausnehmen.

A tut man üblicherweise nicht, deswegen ist es zumindest auf den ersten Blick nicht erforderlich, eine funktion Reintun(int anzahl) zu definieren. Aber rausnehmen sollte man können und dann ist üblicherweise Rausnehmen(int anzahl) sinnvoll. Rückgabewert brauchen wir in diesem Fall nicht, weil mit den Pillen selber nix mehr geschehen muß. Deswegen kann das vom Typ void sein. Ansonsten müßte die Funktion als Pille[] Rausnehmen(int Anzahl) definiert werden. Dann bekommt man durch die Funktion eine Liste von Pillen zurück, die so lang ist, wie die übergebene Anzahl (note: so ist nicht bestimmbar, WELCHE Pillen zurückgegeben werden; die Beschreibung sagt nur, nimm so viele Pillen aus der Schachtel).

Wenn man das hat, kommen eigentlich nur noch für einen relevante Eigenschaften zum Tragen. Schachteln haben ein Ablaufdatum: Danach sind sie nicht mehr zu gebrauchen. In Ableitung davon kann man also zB eine Eigenschaft boolean isOk oder sowas definieren, welche True liefert, wenn das heutige Datum vor dem Ablaufdatum liegt; sonst False. Das Ablaufdatum sollte dann eine schreibgeschützte Eigenschaft sein, die nur(!) durch den Konstruktor gesetzt werden kann.



Und so guckt man das alles in Ruhe durch, gerne mit Stift und Zettel, damit man erstmal vor Augen hat, was man modellieren will und was das für Auswirkungen hat. OO heißt üblicherweise planen.