Seite 1 von 1
Probleme mit Objektorientierung
Verfasst: Montag 8. Februar 2010, 23:42
von Shaldy
Hallo zusammen!
Ich habe folgendes Problem:
Ich möchte eine Klasse erstellen, die einen Koeffizienten eines Polynoms repräsentiert.
Code: Alles auswählen
class Koeffizient(object):
def __init__(self, p_typ, p_details):
self.Typ = typ
self.__Details = p_details
def __str__(self):
#Falls Typ 1 dann ist Koeffizient eine ganze Zahl
if ( self.Typ == 1 ):
return str(self.__Details[0])
elif ( self.Typ == 2 ):
#Typ 2. Der Koeffizient ist ein Bruch
return "(" + str(self.__Details[0]) + "/" + str(self.__Details[1]) + ")"
elif ( self.Typ == 3 ):
#Mathematische Konstante
if ( self.__Details[0] == "PI" ):
return "PI"
elif ( ... )
Funktioniert auch alles ganz toll. Jetzt will ich aber, dass ich bei einem Koeffizienten-Objekt k1 den tatsächlichen Wert haben will, wenn ich den Namen der Instanz schreibe. Zum Beispiel:
Code: Alles auswählen
k1 = Koeffizient(1, [5]) #Ganzzahliger Koeffizient 5
print k1
Jetzt soll bei print k1 einfach der Wert ausgegeben werden. Mach ich das über Magic Members und wenn ja mit welchem?
Verfasst: Montag 8. Februar 2010, 23:48
von jbs
__str__ ist schon richtig, ich verstehe dein Problem gerade nicht so...
Lies dir aber bei Zeiten einmal die PEP 8 (siehe Link in meiner Signatur) durch
.
edit: hmm. also print greift auf __str__ zurück. Du könntest eine Funktion schreiben, die das gewünschte zurückgibt.
Verfasst: Montag 8. Februar 2010, 23:50
von Shaldy
Also ich möchte mit dem Koeffizientenobjekt auch wie mit einer Zahl rechnen können. Also ich möchte einfach eine k1.GetValue() Methode umgehen. Also, dass ich durch bloßes Ansprechen der Instanz den Zahlenwert bekomme.
Verfasst: Dienstag 9. Februar 2010, 08:09
von Klip
Shaldy hat geschrieben:Also ich möchte mit dem Koeffizientenobjekt auch wie mit einer Zahl rechnen können. Also ich möchte einfach eine k1.GetValue() Methode umgehen. Also, dass ich durch bloßes Ansprechen der Instanz den Zahlenwert bekomme.
Na das klingt doch nach einem Fall für
Properties.
Verfasst: Dienstag 9. Februar 2010, 09:09
von EyDu
Hallo.
Wenn du damit rechnen möchtest, dann willst du vielleicht die __add__-, __mul___-, etc. Methoden überschreiben.
Ein paar Anmerkungen hätte ich da noch:
- Diese ganzen Typ==sonstwas-Tests sind überigens sehr unschön. Vielleicht solltest du das Problem einfach über Vererbung lösen. Dann sparst du dir auch dieses, sagen wir mal außergewöhnliche ^^, __Details-Attribut.
- Wirf mal einen Blick in PEP 8. Attribute werden durchgehend in Kleinbuchstaben geschrieben.
- __ bedeutet nicht private! Das dient lediglich der Vermeidung von Kollisionsnamen. Wenn du so etwas wie private haben willst, dann benutze nur einen Unterstrich. Aber selbst damit solltest du sparsam umgehen.
- p_typ und p_details sind sehr seltsame Name. Ich würde sie ausschreiben.
- Um den Ausdruck bei if und elif kommen keine Klammern.
Verfasst: Dienstag 9. Februar 2010, 10:18
von numerix
Da die Koeffizienten Teil eines Polynoms sind und du vermutlich mit diesen Polynomen irgendetwas "machen" willst, wäre zu überlegen, ob du überhaupt soviel Arbeit in eine Koeffizientenklasse steckst, denn letztlich sind das doch bloß Zahlen. So etwas wie Pi mit hineinzunehmen verkompliziert die Sache - abhängig von dem, was genau du vorhast - ggf. ganz erheblich. Wenn du solche irrationalen Konstanten also nicht wirklich brauchst, würde ich mir das sparen.
Evtl. kämest du dann statt einer eigenen Koeffizientenklasse mit dem Datentyp Fraction (aus dem fractions-Modul) aus, zumindest aber könntest du die Koeffizientenklasse unter Verwendung von Fraction erheblich knapper halten, müsstest auch keine eigenen Methoden für die Bruchrechnung implementieren und könntest dich stärker auf eine Klasse Polynom konzentrieren.
Verfasst: Dienstag 9. Februar 2010, 15:52
von Shaldy
Hey Leute!
Erstmal danke fürs Feedback!
Zuerst: Das mit den Klammern weiß ich, nur habe ich mir die Klammern angewöhnt, da ich noch andere Programmier- bzw. Scriptsprachen lerne und nicht immer den Fehler machen will Klammern zu vergessen. Es ist ja auch nicht falsch in Python, von daher dachte ich, es sei nicht so schlimm.
Mit dem fraction Modul hab ich mich leider noch nie beschäftigt. Ich werd mir das mal ansehen.
Der p_details Parameter ist schon wieder weg, da ist mir selbst aufgefallen, dass der sinnlos ist
Das gesamte Script soll am Ende jedes beliebige Polynom als Graph anzeigen können, und seine Nullstellen berechnen.
Die Sache mit dem Graphen wird die aller letzte sein, darum brauchen wir uns hier nicht zu kümmern.
Die Koeffizientenklasse hab ich sowieso nur wegen der Sache mit den Brüchen gebastelt. Ich hab mal gelesen, dass Dezimalzahlen in Python teilweise verändert bzw. nicht korrekt angezeigt werden und das wollte ich vermeiden, in dem ich erstmal Zähler und Nenner speichere und nur wenn nötig den Bruch ausrechne.
Verfasst: Dienstag 9. Februar 2010, 16:05
von cofi
Shaldy hat geschrieben:Es ist ja auch nicht falsch in Python, von daher dachte ich, es sei nicht so schlimm.
Doch es ist falsch. Zwar akzeptiert das der Interpreter, aber die Semantik ist anders, d.h. es kann zu unerwuenschten Ergebnissen fuehren, die man sehr lange nicht findet.
Verfasst: Dienstag 9. Februar 2010, 17:09
von Leonidas
Shaldy hat geschrieben:Zuerst: Das mit den Klammern weiß ich, nur habe ich mir die Klammern angewöhnt, da ich noch andere Programmier- bzw. Scriptsprachen lerne und nicht immer den Fehler machen will Klammern zu vergessen. Es ist ja auch nicht falsch in Python, von daher dachte ich, es sei nicht so schlimm.
Also wenn du Sprachen lernst, solltest du dir auch die Mühe machen, idiomatischen Code zu schreiben. Sonst schriebst du immer nur Java-Code mit jeweils unterschiedlicher Semantik.
P.S.: Was soll denn der Unterschied zwischen einer Programmiersprache und einer Skriptsprache sein?
Verfasst: Dienstag 9. Februar 2010, 17:25
von derdon
Der gleiche Unterschied wie der zwischen Obst und einer Banane
