Schlechter Programmierstil?!

[derrick]

Hm wenn du schon aus "Head First: Design Patterns" zitierst nutz ich die Gelegenheit dochmal um nachzufragen
ob das Buch empfehlenswert ist.
Grüße derrick

[pillmuncher]

Hm wenn du schon aus "Head First: Design Patterns" zitierst nutz ich die Gelegenheit dochmal um nachzufragen
ob das Buch empfehlenswert ist.

Teils-teils. Die Beispiele sind recht gut gewählt, weil einfach zu verstehen. Es macht Spaß, das Buch zu lesen, bzw. es immer mal wieder durchzublättern. Die Diskussions-Richtung im Buch geht immer ungefähr so: Praktisches Problem --> kurzes Durchspielen falscher Lösungsansätze --> Lösung anhand eines Design Patterns --> theoretische Aufarbeitung --> Einordnung unter abstrakte Prinzipien der OO.

Ein weiterer Vorteil für manche ist, dass die Beispiele in Java geschrieben sind. In Gamma et al. sind die Beispiele in C++ oder Smalltalk.

Was mir nicht so gut gefallen hat, waren die nur kurz auf jeweils zwei Seiten dargestellten Design Patterns, die im Buch sonst keinen Platz mehr gefunden haben. Das Visitor Pattern zB. wird völlig verkehrt dargestellt. Da hätte ich es besser gefunden, einen zweiten Band rauszubringen oder das einfach ganz wegzulassen.

Alles in Allem war es kein Fehlkauf. Wenn man das Buch von Gamma et al. dagegen schon kennt und versteht, wird man das Head First Buch eher als Unterhaltungsliteratur ansehen Nicht weil es schlecht wäre, sondern weil man das, was drin steht, ja schon kennt.

Gruß,
Mick.

[lunar]

@pillmuncher: Niemand hat gesagt, dass man Beschreibungen als unmittelbare Grundlage eines Modells nutzen sollte. Sie dienen aber als erster Anhaltspunkt für einen ersten Entwurf. Nicht mehr, aber auch nicht weniger.

Ebenso spielt auch das, was „man schon immer gemacht“ hat, eine wichtige Rolle. Warum? Weil man darin halt die meiste Erfahrung hat, weil es offenbar bisher immer einigermaßen funktioniert hat, und weil es von vielen verstanden wird. Entwurfsmuster sind nichts anderes als die Formalisierung solchen Erfahrungswissens.

Mit Erfahrung und Überlegung kommt man beim Entwurf auch mit simplen Methoden recht weit. Entwurfsmustern und Analysemethoden sind hilfreich, aber keinesfalls obligatorisch. Ihre Anwendung ist insbesondere kein Ersatz für für gesunden Menschenverstand und sorgfältige Überlegung. Die stumpfe Anwendung von Entwurfsmustern ist viel eher schädlich. Bei Deiner State Pattern-Lösung beispielsweise steht die Komplexität der Lösung in keinem Verhältnis mehr zur Trivialität des Problems. Entwurfsmustern sind eben kein Allheilmittel, denn egal was GoF sagt, dass Ändern der Klasse zur Laufzeit ist in Python trotzdem nicht unbedingt empfehlenswert

[pillmuncher]

Ebenso spielt auch das, was „man schon immer gemacht“ hat, eine wichtige Rolle. Warum? Weil man darin halt die meiste Erfahrung hat, weil es offenbar bisher immer einigermaßen funktioniert hat, und weil es von vielen verstanden wird. Entwurfsmuster sind nichts anderes als die Formalisierung solchen Erfahrungswissens.

Ich gebe dir da natürlich größtenteils recht. Ich finde jedoch, dass man die Konventionalität des Bestehenden immer im Auge behalten sollte, und ggf. aus den bestehenden Mustern ausbrechen sollte, AKA Fortschritt. Manches wird dabei funktionieren, manches aber auch nicht. Das wird aber beim Althergebrachten ebenso sein, dass nur manches davon in einer neuen Situation funktionert.

Mit Erfahrung und Überlegung kommt man beim Entwurf auch mit simplen Methoden recht weit. Entwurfsmustern und Analysemethoden sind hilfreich, aber keinesfalls obligatorisch. Ihre Anwendung ist insbesondere kein Ersatz für für gesunden Menschenverstand und sorgfältige Überlegung. Die stumpfe Anwendung von Entwurfsmustern ist viel eher schädlich. Bei Deiner State Pattern-Lösung beispielsweise steht die Komplexität der Lösung in keinem Verhältnis mehr zur Trivialität des Problems. Entwurfsmustern sind eben kein Allheilmittel, denn egal was GoF sagt, dass Ändern der Klasse zur Laufzeit ist in Python trotzdem nicht unbedingt empfehlenswert

Mein Ziel war es gerade, die lokale Komplexität in den Methoden zu verringern. In jeder Methode braucht man so nur auf den derzeitigen Zustand Rücksicht nehmen, und nicht auf andere mögliche Zustände. Dass man vorher in jeder Methode Code zur Diskriminierung derselben Zustände wiederholen musste, widersprach nicht nur DRY, sondern war ein Hinweis darauf, dass diese Zustände globalerer Art waren und entsprechend eine Lösung auf globalerer Ebene erforderten.

Ich habe so immerhin alle if-Statements eliminieren können, bis auf die, die der Validierung von User-Eingaben dienen. Zustands-Steuerung mittels If-Statements sollte in der OO-Programmierung eigentlich gar nicht vorkommen, sondern sollte polymorph über Methoden erfolgen.

Man könnte es übrigens auch so machen

[problembär]

@pillmuncher: Danke für die schönen, auch weiterführenden Beiträge. Nett zu lesen, und handeln meist von interessanten Dingen, die ich noch gar nicht kannte.
Zum Code hier allerdings: Meinst Du nicht, daß Deine Konzepte alle ein bißchen zu kompliziert sind? Ich meine, mein Vorschlag oben ging ja von dem aus, was derrick zuvor schon geschrieben hatte. Noch ein paar Änderungen hier und da, und dann läuft das alles doch schon ganz gut und auf recht einfache Weise.

Mit "State Patterns" und "Design Patterns" überforderst Du doch auch seinen Lehrer.

Gruß

[derrick]

Mit "State Patterns" und "Design Patterns" überforderst Du doch auch seinen Lehrer.

Das Pattern an sich ist nicht wirklich kompliziert und außerdem gab es ja auch den Link mit der relativ
einfachen theoriefernen Erklärung. Ich glaube dass einzige Problem dieses Patterns bzw. des restlichen Codes von Mick
ist dass die Implementierung dieser Konzepte bei einer so kleinen Aufgabe wie meiner einigen overhead produziert.

So far
derrick

[pillmuncher]

@pillmuncher: Meinst Du nicht, daß Deine Konzepte alle ein bißchen zu kompliziert sind? Ich meine, mein Vorschlag oben ging ja von dem aus, was derrick zuvor schon geschrieben hatte. Noch ein paar Änderungen hier und da, und dann läuft das alles doch schon ganz gut und auf recht einfache Weise.

Das mit dem State Pattern war von mir ganz ernst gemeint. Ich halte das für übersichtlich. Dass es unserer Gewohnheit widerspricht, dass Objekte zur Laufzeit ihre Klasse ändern können, heißt ja noch nicht, dass es kompliziert ist.

Die Version mit dem Decorator dagegen war nicht ernst gemeint, deswegen auch der Blinzel-Smiley.

Gruß
Mick.

[pillmuncher]

[State Pattern] Ich glaube dass einzige Problem dieses Patterns bzw. des restlichen Codes von Mick ist dass die Implementierung dieser Konzepte bei einer so kleinen Aufgabe wie meiner einigen overhead produziert.

Sieh's doch mal so: anhand der kleinen Aufgabe kann man solche Sachen viel einfacher ausprobieren und lernen, als an einer großen Aufgabe. Je größer die Aufgabe, desto komplexer, und da wäre es doch gut, wenn man ein paar Tricks im Ärmel hätte, um mit der Komplexität umzugehen.

Gruß,
Mick.

[lunar]

Zustands-Steuerung mittels If-Statements sollte in der OO-Programmierung eigentlich gar nicht vorkommen, sondern sollte polymorph über Methoden erfolgen.

Darüber kann man geteilter Meinung sein, zumindest wenn diese These so absolut formuliert ist. Ich für meinen Teil würde Deine State-Pattern-Lösung aus genannten Gründen nicht akzeptieren ... in meinen Augen ist KISS mit das wichtigste Ziel der Entwicklung, alles andere ist nur Mittel, dieses Ziel zu erreichen, und kein Selbstzweck.

[derrick]

So um das hier nochmals wieder zu beleben hab mich mal an diesem Dispatch Pattern versucht. Der Code funktioniert gut und das Pattern ansich ist nichtmal unelegant, aber ich glaube es ist iwie falsch die Dispatcher Klasse den Automaten erweitern zu lassen. Schauts euch mal an (http://www.python-forum.de/pastebin.php?mode=view&s=207).
Viele Grüße
derrick

[pillmuncher]

In meinen Augen ist KISS mit das wichtigste Ziel der Entwicklung, alles andere ist nur Mittel, dieses Ziel zu erreichen, und kein Selbstzweck.

Einfachheit als Ziel habe ich auch: Der Automat kann sich in einem von zwei Zuständen befinden. Wenn er sich in Zustand A befindet, werden A-Methoden ausgeführt, und wenn er sich in Zustand B befindet, B-Methoden. Wie kann es was einfacheres geben? Vielleicht ist das der Punkt, wo wir beide unterschiedlicher Auffassung sind: ich versuche möglichst einfache Beschreibungen zu finden[*] und diese dann im Code umzusetzen, wohingegen du vielleicht - korrigiere mich bitte ggf. - die Einfachheit der eingesetzten Mittel in den Vordergrund stellst.

[*] Das korrespondiert stark mit meiner Überzeugung, dass der Kern der Programmierung das Analytische und nicht das Technische ist.

Gruß,
Mick.

[pillmuncher]

So um das hier nochmals wieder zu beleben hab mich mal an diesem Dispatch Pattern versucht. Der Code funktioniert gut und das Pattern ansich ist nichtmal unelegant, aber ich glaube es ist iwie falsch die Dispatcher Klasse den Automaten erweitern zu lassen.

Der Dispatcher muss vom Automaten abgeleitet sein, wenn du auf ihm auth() aufrufen möchtest. Dein Beipiel ist ein Grenzfall, finde ich. Das Command Dispatch Pattern bringt hier keinen Vorteil ggü. dem vorherigen table lookup. Ich denke, das Pattern ist für Fälle gedacht, wo direkt aus dem an dispatch() übergebenen String der Methoden-Name ermittelt werden kann. Andererseits, wenn die Automaten-Klasse Teil eines größeren Systems ist, und man nur ein User-Interface anflanschen möchte, könnte man das durchaus so machen, wie bie dir. Da fungiert dann die Dispatcher-Klasse als Adapter für Automaten.

Gruß,
Mick.

[lunar]

@pillmuncher: Nicht die Mittel müssen einfach sein, sondern das Resultat. Und das Resultat ist nicht das Modell, sondern die daraus resultierende Implementierung, also der Quelltext. Denn letztlich ist es der Quelltext, der das Problem löst, und nicht das Modell.

Dein Modell eines Zustandsautomaten ist schon einfach, nur die daraus resultierende Implementierung nicht, weil Du das Modell 1:1 auf den Quelltext übertragen hast, ohne es dabei der Trivialität des Problems entsprechend nochmals zu vereinfachen.

Jedenfalls spricht Deine Lösung für meine These, die ich auch schon in der LISP-Diskussion vertreten habe: Zu viel Abstraktion ist zu viel des Guten

[pillmuncher]

@pillmuncher: Nicht die Mittel müssen einfach sein, sondern das Resultat. Und das Resultat ist nicht das Modell, sondern die daraus resultierende Implementierung, also der Quelltext. Denn letztlich ist es der Quelltext, der das Problem löst, und nicht das Modell.

Wie wäre es, Python als Modellierungssprache anzusehen? IMO hat es genügend deklarative Elemente, um OO-Modellierung auf Quelltext-Ebene zu ermöglichen. Das Ergebnis wären durch Prototyping gewonnene, ausführbare Modelle. Das hieße aber, dass das Modell selbst das Problem löst, ganz einfach weil es mit dem Quelltext identisch ist.

Dein Modell eines Zustandsautomaten ist schon einfach, nur die daraus resultierende Implementierung nicht [...].

Zur if-else-Version (nochmal vereinfacht, wg. der Vergleichbarkeit) sagt pymetrics.py:

Code: Alles auswählen

McCabe Complexity Metric for file bankomat1.py
-----------------------------------------------

          2    Bankomat.__init__
          4    Bankomat.geld_abheben
          3    Bankomat.kontostand_anzeigen
          4    Bankomat.login
          3    Bankomat.logout
          1    Konto.__init__
          1    Konto.auth
          2    __main__
          2    main
          1    main.beenden
          1    main.invalid


COCOMO 2's SLOC Metric for bankomat1.py
----------------------------------------

         67    bankomat1.py

Und zur State-Pattern-Version:

Code: Alles auswählen

McCabe Complexity Metric for file bankomat2.py
-----------------------------------------------

          1    Ausgeloggt.geld_abheben
          1    Ausgeloggt.kontostand_anzeigen
          2    Ausgeloggt.login
          1    Ausgeloggt.logout
          2    Bankomat.__init__
          2    Eingeloggt.geld_abheben
          1    Eingeloggt.kontostand_anzeigen
          1    Eingeloggt.login
          1    Eingeloggt.logout
          1    Konto.__init__
          1    Konto.auth
          2    __main__
          2    main
          1    main.beenden
          1    main.invalid


COCOMO 2's SLOC Metric for bankomat2.py
----------------------------------------

         68    bankomat2.py

Nachfolgend verwende ich CC für McCabe Complexity (Cyclomatic Complexity).

Die Bankomat-Methoden der if-else-Version haben eine CC von drei oder vier, und die der State-Pattern-Version eine von eins oder zwei. Und das bei nur einer Zeile Code mehr. Zwar hat die State-Pattern-Version zwei Klassen und vier Methoden mehr, aber was am Ende zählt ist IMO die Einfachheit des Codes, den man jeweils vor sich hat, und das ist zunächst der innerhalb einer Klasse oder Methode. Die Anzahl der Klassen und Methoden sagt nichts über die Komplexität eines Systems aus, denn es ist leicht, sich ein hochkomplexes System mit nur einer Klasse und einer Methode vorzustellen. Die Länge der Methoden sagt schon eher etwas aus, zumal SLOC laut Les Hatton mit CC korreliert ist. Die Methoden der State-Pattern-Version sind weniger als halb so lang wie die der if-else-Version. Und sum(CC) / SLOC beträgt bei der State-Pattern-Version 0.29 ggü. 0.35 bei der if-else-Version.

Was bei der State-Pattern-Version die geringere Komplexität möglich macht, sind die Invarianten der Zustände, nämlich im ausgeloggten Zustand self.konto == None und im eingeloggten Zustand self.konto != None. Innerhalb der Zustands-Methoden kann man sich darauf verlassen und muss nicht erst nachfragen, in welchem Zustand man sich gerade befindet. Ich finde das einfacher.

Gruß,
Mick.

[problembär]

Hallo,

grau ist alle Theorie. Deshalb hab' ich's jetzt nochmal so geschrieben, wie ich es machen würde:

http://paste.pocoo.org/show/408421/

Das, was man dabei lernen sollte, ist wohl, daß man beim Abheben den Kontostand in den Kunden-Objekten verändert. Und daß dieser neue Kontostand in dem Objekt auch dann erhalten bleibt, wenn man sich ausloggt, sich als ein anderer Kunde einloggt, wieder ausloggt und sich wieder als der ursprüngliche Kunde einloggt.
Das heißt, daß also alle Kontostände erhalten bleiben, selbst wenn man in meinem Beispiel das Objekt des aktiven Kunden "self.user" beim neuen Einloggen auf ein anderes der dem Automaten bekannten Kunden-Objekte lenkt.
Dehalb auch "drei Konten mit unterschiedlichen Benutzernamen" und "um mehrmaliges Einloggen in den Bankautomaten zu ermöglichen" in der Aufgabenstellung.
Ist schon witzig und war mir zuvor nicht völlig klar, daß es sich mit den Objekten so verhält, auch wenn es vielleicht nahelag.
Jedenfalls ist es ein schönes Beispiel, um den Unterschied zwischen der allgemeinen Klasse(nbeschreibung) und dem Objekt, das heißt der einzelnen Instanz dieser Klasse zu zeigen.

Viele Grüße

[Hyperion]

Hallo,

grau ist alle Theorie. Deshalb hab' ich's jetzt nochmal so geschrieben, wie ich es machen würde:

http://paste.pocoo.org/show/408421/

Hui... da könnte man jetzt einiges zu sagen...

Mal in Kürze:

- Ein Kunde hat einen Kontostand?

- Du missbrauchst eine Klasse als Modul (`__init__` sieht verdammt grausig aus!)

- kein PEP8 (speziell Methodennamen)

- zu viel Mischung von Benutzerinteraktion und Logik. Eingaben sollte man davon trennen; ggf sogar außerhalb der Klasse erledigen

- über `eur` (Name? Klingt nach Mnemonic ) müsste man nen eigenen Thread aufmachen

[problembär]

Sing und schwing das Bein,
Laß die Sorgen Sorgen sein,
Hat's dir nicht gefall'n,
dann bohr' dir doch ein Loch ins Knie.
Denn manchen kann man's recht oft tun,
doch allen eben nie.

[Hyperion]

Sing und schwing das Bein,
Laß die Sorgen Sorgen sein,
Hat's dir nicht gefall'n,
dann bohr' dir doch ein Loch ins Knie.
Denn manchen kann man's recht oft tun,
doch allen eben nie.

Du vermischst hier Intro und Outro

Fraggles waren schon cool

[problembär]

Hallo,

na gut, Deine Anmerkungen zu meinem Code sind ja eigentlich auch nicht schlecht.

Ein Kunde hat einen Kontostand?

Stimmt, das ist etwas unglücklich. Das hatte ich noch von derrick übernommen. Die Klasse sollte wohl eher "Konto" heißen, und statt "self.name", dann "self.inhaber" oder so.

Ich hab' Programmieren ja nicht in der Schule oder an der Uni gelernt, sondern mir diese Sachen selbst angelesen. Dabei komme ich von Sprachen ohne OOP: Früher 8-bit BASIC, dann C (das aber für mich zu schmerzhaft war). Jedenfalls hatte ich immer große Mühe, OOP zu verstehen und auch zu wollen. Bei den Grundlagen geht es jetzt einigermaßen, aber die höhere Theorie ist mir immer noch fremd. Ich mag auch Platon nicht, sondern eher Aristoteles, Kant und die Chinesen (Konfuzius usw.).
Bei Klassen hatte ich einmal das Gefühl, das mit der "Abbildung der Wirklichkeit" sei doch alles nur Gerede. In Wirklichkeit ist eine Klasse technisch einfach nur ein Container, der einige Variablen und Funktionen enthält, die man dann über Instanzen der Klasse ansprechen kann. Interessanterweise habe ich bemerkt, daß diese Sichtweise in Perl auch so umgesetzt wurde: Dort ist eine Klasse ein spezielles "package", wobei ein solches package einfach einen Namensraum definiert und eigentlich dazu gedacht ist, Module zu schreiben.
Aus dieser Sichtweise heraus ist der Name des Containers nicht so wichtig, es ist mehr oder weniger egal, ob der nun "Kunde" oder "Konto" heißt.
An dieser Stelle stehe ich gerade. Und komme ganz gut damit aus. Aber ich schreibe keine saubere OOP. Und weiß auch nicht, ob ich das lernen muß und will. Vielleicht könnt ihr mir etwas Literatur empfehlen (denn "Python GE-Packt", das ich sonst (trotz leichter und vereinzelter Ungenauigkeiten) sehr schätze, ist an dieser Stelle leider etwas dünn)?

Du missbrauchst eine Klasse als Modul (`__init__` sieht verdammt grausig aus!)

Ok, nach dem oben gesagten, verstehst Du das jetzt vielleicht etwas besser. Obwohl Du's wahrscheinlich immer noch kritisieren wirst.

kein PEP8 (speziell Methodennamen)

Na ja, man kann nicht alles haben.

zu viel Mischung von Benutzerinteraktion und Logik. Eingaben sollte man davon trennen; gegebenenfalls sogar außerhalb der Klasse erledigen

Immerhin hab' ich das mit ".getChoice()" schon ein bißchen versucht. Würdest Du das wirklich auch für ganz einfache Eingaben strikt umsetzen?

über `eur` (Name? Klingt nach Mnemonic ) müsste man nen eigenen Thread aufmachen

Ja, mach' ich wohl bald mal. Die Frage kommt sowieso immer wieder mal. Manche empfehlen da wohl das "locale"-Modul, aber warum sollte man nicht eine eigene kleine Funktion schreiben, die man vollständig unter Kontrolle hat, während man bei dem "locale"-Modul erst sicherstellen muß, daß auch wirklich die richtigen locales eingestellt sind? Für Perl gibt es gleich mehrere Module zur Währungsumwandlung. Es scheint nicht so ganz einfach zu sein, daß für viele Fälle richtig hinzubekommen. Bei meiner Funktion dagegen weiß ich, was sie tut und was man als Rückgabewert erwarten kann. Ich finde das praktischer so. Auch wenn man sie vielleicht noch besser schreiben könnte.

Insgesamt würde mich aber schon interessieren, wie Du das denn mit "richtiger OOP", PEP 8, Pi-pa-po, usw. in orthodoxem Python schreiben würdest.
pillmuncher hat ja auch schon einen Vorschlag gemacht, den ich aber schon vom Konzept her leider kaum nachvollziehen kann (obwohl er bestimmt gut ist, das will ich gar nicht bestreiten).

Aber wichtiger als mein Code war mir eigentlich auch das, was die Aufgabe meiner Meinung nach zeigen sollte (was ich in dem anderen Posting weiter oben beschrieben hatte). Es ist doch erstaunlich, daß hier seitenweise diskutiert wurde, aber dazu bisher niemand etwas geschrieben zu haben scheint.

Gruß

[Hyperion]

Aus dieser Sichtweise heraus ist der Name des Containers nicht so wichtig, es ist mehr oder weniger egal, ob der nun "Kunde" oder "Konto" heißt.

Dem wage ich zu widersprechen: Wäre ein Name nicht wichtig, so könnten wir auch alles nur mit x-en, i-s usw. zupflastern. Ein Name ist für das Verständnis des Codes sehr wichtig. Du benutzt aus der Standard-Lib ja auch sachen wie `list`, `sum`, usw. Stell Dir vor diese Funktionen hießen einfach nur `func_a`, `func_b` oder so. Damit wäre es schwer sich zu merken, was die nun genau machen, oder?

Insgesamt würde mich aber schon interessieren, wie Du das denn mit "richtiger OOP", PEP 8, Pi-pa-po, usw. in orthodoxem Python schreiben würdest.
...
Es ist doch erstaunlich, daß hier seitenweise diskutiert wurde, aber dazu bisher niemand etwas geschrieben zu haben scheint.

Naja, man muss ja nicht immer selber eine komplette Lösung abgeben Und es gab doch iirc einige Lösungen, die ganz gut aussahen - Pillmuncher hatte doch mehrere Lösungen, oder? Muss ich gleich noch mal nachgucken.