experimente mit klassen!

Leonidas · Freitag 23. April 2004, 12:33

Milan hat geschrieben:Es ist einfach praktischer "echtes" OOP zu machen, da wie oben schon geschrieben bei Änderungen kein Mehraufwand dadurch entsteht, dass ich alle aufrufenden Programmteile ändern muss.

Das ist halt die flexibilität von Python. Wenn du nur schnell was hinhackst kannst du auch alte Klassen nutzen

Dookie · Freitag 23. April 2004, 15:24

Hi rolgal,

über serverpush hab ich auch nur mal was gelesen, wurde aber nicht empfohlen und ich kam noch nicht in die Verlegenheit dieses zu verwenden. Wie es damit unter Python ausschaut weiss ich nicht. Zum Chat, ich würde da eher ein Script versuchen, daß mit einem IRC-Channel kommuniziert, dann können Freaks auch direkt in den IRC-Channel gehen und für die Daus gibts ein Webinterface.

Gruß

Dookie

Gast · Freitag 23. April 2004, 19:53

hi dookie, milan, leonidas und alle anderen die sich noch an der diskussion beteiligen wollen!

ist möglich ein ganz simples beispiel zu demonstrieren, in dem ich sehen kann, wie sich meine momentanen ideen von oop fatal auswirken. und zwar konkret. so dass es mir wie ein stromschlag durchs gehirn fährt.

bei all der argumentation, der ich hypothetisch folgen kann, .....ja, das ist ein gutes wort. dazu fällt mir noch was ein.

die gitarristen, konzert(bzw.)klassische gitarristen, haben eine sehr konkrete vorstellung davon, eigentlich gesetzmaessigkeiten, wie sie problemstellung auf dem instrument lösen.
es gab eine zeitlang eine kultur fingersätze zu entwerfen, die alle möglichen eventualitäten gleich mitberücksichtigen.

ich kann dir nur sagen, 90% haben diese vorgehensweise verschmissen. es hat sich herausgestellt, dass viele dieser konzepte zum selbstzweck bestehen.
so ähnlich klingt das alles für mich in dieser diskussion. "nicht sauber, kein richtiges oop (was auch immer das in python ist), wenn der und der fall unter jenen und diesen umständen eventuell auftritt.

programmieren programmierer zu viel "design code"? gibt es immer mehr bugs, bzw. schwächen in den funktionalitäten von programmen, weil programmierer sich in erster linie damit beschäftigen, dass sie ihren code ansehen und sagen können: "sauber, richtig feines oop"

ja mit fingersätzen war es dann irgendwann auch so, sie waren interlektuell genial, entsprachen allen vorstellungen die man so hatte, und klangen trotzdem oft schlecht.

mfg

rolgal

Milan · Freitag 23. April 2004, 21:10

Hi. Du möchtest ein konkretes Beispiel, von dem was ich meine. Ok, kannst du haben. Du erinnerst dich bestimmt an die Klasse für Brüche, die ich in den Codesnippets bereitgestellt habe. Ich komme auf sie zurück, weil ich sie auf new-style trimmen möchte und dir das ganze auch an ihr gut demonstrieren kann. Bei mir steht sie in meinem eigenem Modul "utils". Nun folgendes Beispiel, bei dem ich einmal von außen auf die Klasse zugreife und einmal über die definierten Schnittstellen, nämlich die "normalen" Rechenoperationen:

Code: Alles auswählen

>>> from utils import Bruch as B
>>> a=B(1,1)
>>> a2=a*0.5
>>> a2.gettuple()
(1L, 2L)
>>> a.z=0.5
>>> a.gettuple() # (1/2) ist ja formal dasselbe wie (0.5/1)
(0.5, 1L)
>>> b2=a2+1
>>> b=a+1
>>> b2.gettuple(),b.gettuple() # aber siehe da... meine Klasse meint etwas anderes
((3L, 2L), (1L, 1L))

So, nun siehst du es hat einen Unterschied, ob ich von außen zugreife (a) oder mich an die Norm halte, wie es gedacht war (a2). Natürlich kannst du jetzt sagen, die Klasse war nicht für Gleitkommazahlen gedacht, da kann (1/2) ist ja formal dasselbe wie (0.5/1) dasselbe sein wie es will. Nur... woher weiß man das, wenn man den Quellcode nicht selber geschrieben hat?

Mit Properties könnte ich das abfangen:

Code: Alles auswählen

#ohne Klasse, nur um das Prinzip zu zeigen
    def set_z(z):
        z=z*B(1,1)
        self.z,self.n=z.gettuple()
    z=property(fset=set_z)

Aber du siehst: es erfordert Merhaufwand, eine solche "Kleinigkeit" auszuschließen. Nur im letzteren Beispiel kann die Klasse auf die Änderung reagieren, im obigen hat sie keine Chance.

Und zu der These OOP würde nur für sich existieren: das kommt darauf an, wie du es einsetzt. Wenn man es im Unterricht für die Addition von 1+1 einsetzt (übertrieben) mag das stimmen, aber schau dir mal Quelltexte von Spiele, Programmen, etc an und du wirst sehen, dass es nicht so ist. Da gibt es fast nur OOP und das spricht ja für sich. (zur Not tun es auch die Pythonmodule ftplib, smtplib, poplib).

So, ich hoffe mal deine Weltanschauung wenn nicht gerade gerückt, so wenigstens erschüttert zu haben.

mfg, Milan

Gast · Freitag 23. April 2004, 21:33

hi milan!

muss das mal in ruhe durchdenken.

So, ich hoffe mal deine Weltanschauung wenn nicht gerade gerückt, so wenigstens erschüttert zu haben.

ich hoffe, dass der zynismus in diesem und in einem deiner einleitenden sätze eine einbildung meiner müdigkeit ist.

erschüttern tut mich gar nichts, und wenn die argumentation stichhaltig ist, dann haben wir ein fallbeispilel und nicht mehr. weisst du was ein fallbeispiel in der wissenschaft bedeutet?

mfg

rolgal

Dookie · Samstag 24. April 2004, 10:45

Hi rolgal,

ich denke mal Du Spielst auf die oftmals wirklich blöden Beispiele in vielen Büchern zu OOP an. Darüber haben wir uns ja auch schonmal unterhalten.

Schau Dir nur mal die ganzen GUI-Geschichten an, das ist OOP pur. Selbst GTK ist ein Paradebeispiel für Objektorientierte Programmierung, obwohl es in C gecodet ist.
Viele Simulationsprogramme (dazu zählen auch die von Milan bereits angesprochenen Spiele) sind mit OOP wirklich viel einfacher zu realisieren als mit prozeduraler oder funktionaler Programmierung.
Für manche Sachen bringt OOP aber wirklich nichts, aber dafür erlaubt Python ja auch prozedural und funktional zu Programmieren.

Gruß

Dookie

P.S.: ein bisschen Zynismus muss schon erlaubt sein.

Gast · Samstag 24. April 2004, 11:01

hi dookie!

die diskussion verliert ein bisschen an sinn, weil wir zuviele aspekte aufeinmal diskutieren.

1. ich habe nie gesagt dass oop sinnlos ist. wann? wo? wenn ja, war ich betrunken, nehme es zurück:-))

2. ich habe die art wie z.b du und milan oop einsetzt und nach welchen regeln ihr es anwendet nicht grundsätzlich in frage gestellt. bei projekten an denen mehrere leute arbeiten, kann ich mir schon viel eher vorstellen, dass meine idee gleich zum vergessen ist.

3. ich habe lediglich versucht die vor- und nachteile zu erörtern, die auftreten wenn man klassen und/oder objekten von aussen atrribute und/oder methoden zuweist.

dieser satz von milan hier

Natürlich kannst du jetzt sagen, die Klasse war nicht für Gleitkommazahlen gedacht, da kann (1/2) ist ja formal dasselbe wie (0.5/1) dasselbe sein wie es will. Nur... woher weiß man das, wenn man den Quellcode nicht selber geschrieben hat?

erinnert mich sehr an viele situationen meiner nunmehr 16jährigen gitarristischen laufbahn:

natürlich kannst du das hier jetzt so lösen, aber was wenn du mal ein stück spielst, in dem .....dann hast du das jetzt schon gelernt.

ich sagte ja schon : in 9 von 10 fällen hat sich das als methode zum selbstzweck erwiesen.

für euch vielleicht schwierig nachzuvollziehen. aber die technischen konzepte erinnern mich wirklich oft an themen wie oop beim programmieren.

4. ich sehe noch immer nichts fatales, wenn ich z.b. meine klassenmodul so lösen würde, wie ich es gezeigt habe. nein ich bin nicht darin verliebt und ich weiss auch noch gar nicht, ob ich es so lösen werde.

aber schaun wir doch mal gerade den verlauf unseres gesprächs an.

du hast ein bsp. gebracht mit einer webseite. das objekt kann nicht reagieren, - ich sagte drauf, es kann, weil ja sowieso der browser den inhalt neu laden müsste, und somit __str__ ja wieder ausgeführt wird. daraufhin hast du serverpush erwähnt, von dem du dich dann aber auch wieder distanziert hast.
du kannst sicher nachvollziehen, dass das alles nicht so ist, dass ich mir sage:

den pythonentwicklern ist beim entwurf und design und der implementierung von oop ein schwachsinn unterlaufen, sie haben sich nichts dabei gedacht und man sollte am besten jdm. anfänger nie was von der option sagen usw.

ich denke das ist der kern der diskussion.

mfg

rolgal

Dookie · Samstag 24. April 2004, 11:47

Hi rolgal,

also zurück zur eigentlichen Frage, warum sollte man nach Möglichkeit nicht von Aussen auf die Attribute eines Objekts zugreifen, wenn es dafür eine definierte Schnittstelle (Methoden, Properties) gibt und warum erlaubt Python das trotzdem?

Einen Punkt hast Du ja selber schon angesprochen, wenn mehrere Leute an einem Projekt arbeiten und jeder irgendwie an den Objekten herumpfuscht, geht das zu 99.99% schief.
Wenn Du Module machst, und sie in einem anderen Projekt wiederverwenden willst, bist Du sicher auch gut beraten dich an die OOP-Vorgaben zu halten und die Vererbung von Klassen zu benutzen um Objekte mit neuen Eigenschaften zu versehen anstatt wahllos neue Attribute an ein Objekt zuzuweisen.
Willst Du Deine Module weitergeben, so ist die Dokumentation beim Klassen- und Methodenkonzept von Python auch viel einfacher als wenn du extra zu jedem Attribut ausführen musst worfür es gebraucht wird, wobei eh keiner die extra Dokumentation liest, in Pydoc schaut doch eher einer rein.

Warum erlaubt Python das trotzdem?
Bei jedem Zugriff auf ein Attribut müsste geprüft werden, ob dieser, in dem Kontext, gestattet ist oder nicht. Jeder Test aber kostet Rechenzeit und ist so der Performace eines Programms abträglich.
Ein bisschen Eigenverantwortung sollte beim Programmierer liegen und in gewissen Ausnahmefällen oder zum Testen eines Programms könnte es auch mal sinvoll sein ein Attribut direkt zu ändern oder abzufragen, am, vom Entwickler der Klasse, vorgesehenen Weg vorbei.

Es ist ja auch möglich auf eine heisse Herdplatte zu fassen, allerdings macht man das nur einmal, und weiss dann warum jeder davon abrät.

Gruß

Dookie