OOP-Entwurfsprinzip auch für Python gültig?

[Goswin]

Immer wieder werde ich in meiner Programmierarbeit hingewiesen auf das Entwurfsprinzip: "Programmiere auf eine Schnittstelle hin, und nicht auf eine konkrete Klasse". Nun sind aber die Kollegen, die mir das empfehlen, entweder Java-Programmierer oder C++-Programmierer; viele kennen überhaupt keine dynamisch typisierten Sprachen. Ich konnte bisher nie nachvollziehen, wieso ich meine Klassen von abstrakten Oberklassen ableiten soll, die überhaupt nichts tun ( "class Klassenname_Schnittstelle(object): pass" ).

Sind Schnittstellen dieser Art bei Python überhaupt sinnvoll? Wenn ja, warum?

[sea-live]

ziemlich einfach
um einem objekt seine aktuelle eigenschaft zu entlocken sind schnittstellen
sehr sinnvoll

gib mir deine farfe ist eine schnittstelle

def getcolor():

[Rebecca]

Den einzigen Sinn, den ich in so einer Klasse sehe, ist, dass man damit Variablen deklarieren kann, und die Funktionalitaet braucht man in Python ja nicht. Aber wenn man eine Variable mit der abstrakten Klasse deklariert hat, kann man in Java trotzdem nicht auf die Methoden der Objekte zugreifen, die in der abgeleiteten Klasse definiert werden, oder? Also doch nicht so ganz sinnvoll?

PS: Ich lese mich gerade durch "Head first Design Patterns" durch, und denke auch, dass man manche Dinge in Python anders loesen wuerde. Waere mal interessant, Meinungen anderer Leute dazu zu hoeren...

[Leonidas]

Immer wieder werde ich in meiner Programmierarbeit hingewiesen auf das Entwurfsprinzip: "Programmiere auf eine Schnittstelle hin, und nicht auf eine konkrete Klasse". Nun sind aber die Kollegen, die mir das empfehlen, entweder Java-Programmierer oder C++-Programmierer; viele kennen überhaupt keine dynamisch typisierten Sprachen.

Daher sind solche Tipps dann mit Skepsis zu begegnen, denn Konzepte (in meinen könnte man einiges davon auch als Defekte bezeichnen) aus Java in Python oder andere dynamische Sprachen zu übertragen ist oftmals keine gute Idee, da viele Dinge für die man in statischen Sprachen Lösungen bauen muss, sind in dynamischen Sprachen schon gelöst.

Als Beispiel könnte hier Copland herhalten, ein Dependency-Injection-Framework für Ruby dass von einem Java-Programmierer geschrieben wurde. Irgendwann wurde er dann darauf hingewiesen, dass man statt die ganze Konfiguration in YAML/XML zu machen, doch auch Ruby gehen würde. Daraufhin wurde Needle geschrieben. In seiner weiteren Programmierarbeit hat er dann irgendwann festgestellt, dass man für DI eigentlich gar kein Framework braucht.

Ich konnte bisher nie nachvollziehen, wieso ich meine Klassen von abstrakten Oberklassen ableiten soll, die überhaupt nichts tun ( "class Klassenname_Schnittstelle(object): pass" ).

Das kannst du dir unter Java ein wenig wie eine formalisierte Version von Duck Typing vorstellen, bei der die syntaktischen Schnittstellen festgelegt werden. Das klingt für Java-Programmierer wichtig, weil dort das Typsystem viel stärker auf Typen fokussiert ist statt auf Verhalten aber wie die Python-Erfahrung gezeigt hat, ist so etwas gar nicht mal so notwendig.

Gerade die Möglichkeit, eine Klasse als Objekt zu übergeben (also quasi First-Order-Classes) ohne sie zu instanziieren ist eine Fähigkeit, deren Sinn Java-Programmierer oft nicht sehen und stattdessen dicke Frameworks mit viel XML schreiben um selbiges zu erreichen.

PS: Ich lese mich gerade durch "Head first Design Patterns" durch, und denke auch, dass man manche Dinge in Python anders loesen wuerde. Waere mal interessant, Meinungen anderer Leute dazu zu hoeren...

Ja, ganz recht. Wenn man sich das Gang of Four-Buch ansieht und diese ganzen in Java populären Patterns ansieht dann sind viele davon in Python so simpel, dass man so etwas ohne das Buch selbst erfinden kann, weil da einfach nichts dabei ist. Etwa das Factory-Pattern. Andere wie das Singleton/Borg-Pattern sind nicht unbedingt sinnvoll und wieder andere wie das Visitor-Pattern sind viel hübscher wenn man sie durch Multimethods ersetzt.

[Goswin]

@sea-life:
Es tut mir leid, aber ich verstehe NIX von deiner Antwort. Ich verstehe nicht einmal, ob sie ernst gemeint ist oder nicht. Und was eine "farfe" sein soll, schon garnicht.

Wie soll ich einem Objekt aus einer Unterklasse Eigenschaften "entlocken" können???

[helduel]

Moin,

@sea-life:
Es tut mir leid, aber ich verstehe NIX von deiner Antwort. Ich verstehe nicht einmal, ob sie ernst gemeint ist oder nicht. Und was eine "farfe" sein soll, schon garnicht.

Ich antworte mal stellvertretend: War ein Tippfehler. Er meinte Farbe (getcolor).

Wie soll ich einem Objekt aus einer Unterklasse Eigenschaften "entlocken" können???

Indem man auf Attribute oder eben auf Methoden zugreift - wie getcolor().

Gruß,
Manuel

[veers]

Sieh dir mal die Abstract Base Classes an, das klingt auch enterprisy genug um Java Programmierer etwas zu beschäftigen

- Jonas

[Leonidas]

Sieh dir mal die Abstract Base Classes an, das klingt auch enterprisy genug um Java Programmierer etwas zu beschäftigen

Oh, dafür eignet sich auch gut PEAK. Wobei das ja noch irgendeinen Wert hat. Für Beschäftigungstherapie gibt es ja auch noch Spring Python

[BlackJack]

@Goswin: Wenn man in Java direkt gegen eine Klasse implementiert, kann man diese Klasse nicht einfach gegen eine andere Implementierung austauschen, ohne dass man den Code, der die Klasse verwendet, auch ändern muss. Wenn man gegen ein Interface programmiert, kann man ohne Änderungen im eigenen Code machen zu müssen, alle Klassen verwenden, die das Interface implementieren.

Das ist in Python aber gar kein Problem, weil da eben nicht der Typ geprüft wird, sondern nur das Verhalten der Klasse stimmen muss, gegen die man programmiert. Die Klassen lassen sich auch ohne Interface problemlos austauschen.

[Panke]

In C++ gibts dafür dann Templates.

[Leonidas]

Für alle die es brauchen gibt es auch zope.interface und PyProtocols (was mit "Protocols" auch BlackJacks bevorzugten Oberbegriff von Typcheck/Verhaltenscheck benutzt).

[Darii]

In C++ gibts dafür dann Templates.

Das ist dann aber wieder was anderes.

[sma]

Goswin, ich würde sagen, Schnittstellen sind gut, aber ein Konzept, dass sich nicht als Code in einem Programm wiederfinden muss. Daher würde ich in Python nicht ein Java-Interface als abstrakte Klasse realisieren. Das wäre nur Code-Ballast.

Schnittstellen in Java sind außerdem wichtig, um Komponenten testbar zu halten. Sie lösen ein Problem, dass man in Python gar nicht hat. Daher gibt es auch keinen Zwang, syntaktisch da etwas zu machen.

Stefan

[Panke]

In C++ gibts dafür dann Templates.

Das ist dann aber wieder was anderes.

Da bin ich anderer Meinung. Die Standardcontainer sind auch auf eine Schnittstelle hin programmiert: Das die Inhalte den Kopierkonstruktor und den Kleiner-gleich-Operator besitzen.

Ich wollte damit nämlich gerade dadrauf aufmerksam machen, dass 'Auf eine Schnittstelle hin programmieren' nicht zwangsläufig bedeutet ein Java Interface Gegenstück zu erfinden.

[BlackJack]

@Panke: Templates sind etwas anderes als die STL-Container. Man kann mit Templates wesentlich mehr anstellen als generische Container zu implementieren.

[Goswin]

Ich lese mich gerade durch "Head first Design Patterns" durch, und denke auch, dass man manche Dinge in Python anders loesen wuerde. Waere mal interessant, Meinungen anderer Leute dazu zu hoeren...

Ich schlage mich auch mit dem gleichen Buch herum. Leider sind die Begründungen der Entwurfsprinzipien alle auf Java zugeschnitten, und mein Java ist unzureichend, um das WESENTLICHE dieser Begründungen zu verstehen.

Das Buch ist offenbar nur für Java-Programmierer benutzerfreundlich, für andere ist es eine harte Nuss. In der Einführung heißt es auf Seite xxiv (für wen ist dieses Buch): "Sie müssen kein Java-Guru sein" und "Sie müssen keine fortgeschrittenen Java-Kenntnisse haben". Das trifft alles NICHT DEN KERN der Sache. In der Tat muss man anfangs keine fortgeschrittenen Java-Kenntnisse haben, ABER man muss den Willen und die Zeit haben, sich solche fortgeschrittenen Java-Kenntnisse anzueignen, sonst ist das Buch fast nutzlos.

[Goswin]

Goswin, ich würde sagen, Schnittstellen sind gut, aber ein Konzept, dass sich nicht als Code in einem Programm wiederfinden muss. Daher würde ich in Python nicht ein Java-Interface als abstrakte Klasse realisieren. Das wäre nur Code-Ballast.

Ja, ich denke, meine Schnittstellen werde ich voraussichtlich als docstrings implementieren.

Schnittstellen in Java sind außerdem wichtig, um Komponenten testbar zu halten. Sie lösen ein Problem, dass man in Python gar nicht hat.

Aber testen wird man die (konkreten) Python-Komponenten wohl auch müssen, oder?

[Leonidas]

Schnittstellen in Java sind außerdem wichtig, um Komponenten testbar zu halten. Sie lösen ein Problem, dass man in Python gar nicht hat.

Aber testen wird man die (konkreten) Python-Komponenten wohl auch müssen, oder?

Ja natürlich muss man die Komponenten noch testen, aber Python erzwingt keine Typkorrektheit und dadurch ist Mocking im Vergleich zu Java trivial. Ebenso die Möglichkeit dass man Klassen und Funktionen als Objekte direkt herumreicht, ohne sie instanziieren zu müssen oder in Instanzen von Dummyklassen verpacken zu müssen macht das testen von Python-Code auch ohne aufwendige Design-Patterns einfacher. Zudem gibt es keine privaten Attribute also kann man an einer zu testenden Klasse einige Attribute trivial durch Mock-Objekte ersetzen, durch simple Zuweisung.

[CerebrosuS]

Hi,

ich gebe auch einfach mal meinen Senf zu der ganzen Angelegenheit. Also ...

Ich programmiere selber auch Java und C++, Python jedoch erst seit kurzem. Das Problem was der Threadersteller erkannt hat, ist die dynamische Typisierung. Warum sollte ich ein abstraktes Objekt erstellen, wenn man es nicht mit der Typisierung ausnutzen kann. Da ich erst seit kurzem in Python involviert bin, bitte ich um Verständniss, sollte ich Halbwahrheiten verbreiten.

Wenn ich ein Objekt meine Vorstellung auf ein gestelltes Automatisierungsproblem abbilde und dadraus mein Programm erstelle spielen Typisierungen eine wichtige Rolle, schließlich bekomme ich syntaktische und semantische Probleme in der gewählten Sprache, wenn ich jene nicht ab und zu kontrolliere. Man sollte grundsätzlich auf Typisierungsmechanismen nciht verzichten. In Python ist das, wenn ich es bis jetzt rchtig überblickt habe mit "isinstance()" sehr gut lösbar. Wenn ich also festellen möchte welches Objekt in einer gegebenen Variable ist, um es dann effizient zu nutzen, bsp. die richtige Eigenschaft abzufragen, sollte ich eine Typisierungsprüfung vornehmen. ANsonsten ist dein Programm nicht weit davon entfernt sich selbständig zu machen. Und genau hier setzt Abstract wieder ein. In Python wird keine statische Typisierung geboten, also muss ich Objekte abfragen und diese Typisierung im gewissen Maße kontrollieren. Wie gesagt hier kommt das Abstrakte wieder rein. Denn arbeite ich nurnoch mit abstrakten Objekten, kann ich wunderbar den modularen Code erweitern und zugleich den alten Code belassen wie er ist. Was ja einer der Hintergründe für OOP ist.

Grüße

[DasIch]

@CerebrosuS Du hast Python absolut nicht verstanden. Typprüfung ist absolut unnötig und soweit als möglich zu vermeiden. Dadurch entstehen auch keine Probleme, im Gegenteil.