Properties und Getters

[BlackJack]

Naja irgendwo fangen Vergleiche dann an zu hinken, weil so etwas wie eine Tan-Liste oder einen Tresor gibt's IMHO nicht. Ich sehe das "privatisieren" nicht als Methode um mich oder mein "Haus" zu schützen, sondern um andere davor zu bewahren sich auf etwas zu stützen, was ich nach aussen nicht garantieren möchte. Wenn der Nachbar zum Beispiel meine elektrische `_heckenschere` mit benutzt und ich die irgendwann durch ein atomar betriebenes `_lichtschwert` ersetze, kann der Nachbar das nicht so verwenden wie bisher, weil's nicht in die Steckdose gesteckt wird und er vielleicht keine passenden Brennstäbe hat.

Wenn man wirklich einen Tresor hat, sind andere Mittel gefragt als der Zugriffsschutz, den die üblichen Programmiersprachen bieten.

[Leonidas]

Das Schutzmaßnahmen ausgehebelt werden können ist bekannt. Erst kürzlich habe ich gesehen das man sogar relativ einfach an die Daten verschlüsselter Festplatten kommt.

Aber man muss sie auch nicht gleich auf dem Präsentierteller anbieten

Also Seköriti by obsköriti?

Wenn jemand dran will und er halbwegs was kann oder in der Lage ist eine Suchmaschine zu verwenden dann kommt er ran. Der Mechanismus in Java ist nicht zur Sicherheit gedacht sondern soll die Objekte kapseln. Dass man mit dem Hammer auf die Kapsel drauf hauen kann ist klar.

[Gnushi]

Hi Burli!

Das wollte ich noch fragen. Was ist an Settern und Gettern und private members so schlecht?

Was ich mir selbst immer wieder hinter die Ohren schreibe ist, dass man getter() und setter() selten braucht. Ich bin meistens nur zu faul, das auch einzusehen. "Private" Klassenkameraden verwende ich, um auch mir selbst etwas Übersicht im Quelltext zu geben: Eine _private Methode ist nur für den (Klassen-) internen Gebrauch, ein __sehr_privates Attribut birgt beim Zugriff die Gefahr von Seiteneffekten. (Den ersten Teil davon habe ich aus PEP 8 )

Liebe Grüße

GnuShi

[Marky]

Hallo Leute,

ich muss das Thema nochmal aufgreifen.
Also zunächst mal verstehe ich so manche Argumentation gegen private members nicht so ganz.
Im Grunde genommen ist doch Datenkapselung ein Paradigma objektorientierter Programmierung. Wenn man von privaten Variablen und Methoden/Funktionen spricht, dann geht es doch im Wesentlichen genau darum und nicht wie ich durch die Hintertür dann doch noch auf private Daten eines Objektes zugreifen kann.
Wenn ich zwei Softwaremodule habe, die miteinander kommunizieren, dann geht das normalerweise über Schnittstellen nach außen hin (Information Hiding).
Wenn ihr an euer Auto einen Anhänger dranhängt, dann macht ihr den doch auch an der Anhängerkupplung fest und öffnet nicht den Kofferraum und legt die Deichsel auf den Rücksitz?!

Dass in Python nichts wirklich private ist, ist ja ok und eben sprachabhängig, aber verändert das dann auch den Sinn von Datenkapselung ... ???

[Leonidas]

Wenn ich zwei Softwaremodule habe, die miteinander kommunizieren, dann geht das normalerweise über Schnittstellen nach außen hin (Information Hiding).

Die Schnittstellen sind doch auch ohne Information Hiding da, nicht wahr? Schnittstellen definieren ja welche Protokolle vom Objekt unterstützt werden, nicht was nicht unterstützt wird.

Du kannst auch den Abschnitt zu Datenkapselung lesen, Florian beschreibt das eigentlich ganz passabel.

Wenn ihr an euer Auto einen Anhänger dranhängt, dann macht ihr den doch auch an der Anhängerkupplung fest und öffnet nicht den Kofferraum und legt die Deichsel auf den Rücksitz?!

Wenn ich einen Anhänger ans Auto dranhänge, mache ich den auch nicht an einem Esel fest und binde den Esel am hinteren Scheibenwischer fest. Aber wo hat dein Vergleich irgendeine Ähnlichkeit mit OOP in Python?

Dass in Python nichts wirklich private ist, ist ja ok und eben sprachabhängig, aber verändert das dann auch den Sinn von Datenkapselung ... ???

Wer sagt denn dass Datenkapselung syntaktische Unterstützung braucht? Datenkapselung in Python kannst du ja auch implizit sehen, so wie Interfaces auch. Dir werden eben weniger Hürden vor die Beine geworfen um die Datenkapselung aufzubrechen. In Java könntest du über Reflection die Kapselung überwinden, in Python über den Zugriff auf Attribute die mit ``_`` beginnen.

Es gibt auch den Ansatz: alles was dokumentiert ist, ist die Schnittstelle, der Rest ist private. Es ist eben mehr implizit und man kann über Properties Datn kapseln. Wenn jemand mutwillig hinter die Kapselung greift (das kann ja durchaus manchmal gute Gründe haben) dann ist es eben genauso möglich wie wonders auch, nur eben einfacher.

Pythons OOP-Ansatz ist weniger dogmatisch und strikt und hat nicht für alle Sachen syntaktisch/semantische Unterstützung. Ich denke gerade das ist es, was mir daran gefällt.

[Marky]

Wer sagt denn dass Datenkapselung syntaktische Unterstützung braucht? Datenkapselung in Python kannst du ja auch implizit sehen, so wie Interfaces auch. Dir werden eben weniger Hürden vor die Beine geworfen um die Datenkapselung aufzubrechen. In Java könntest du über Reflection die Kapselung überwinden, in Python über den Zugriff auf Attribute die mit ``_`` beginnen.

Das sagt niemand, nur finde ich syntaktische Unterstützung nicht verwerflich und sie zu nutzen auch nicht. Wenn alles nur aus Konventionen besteht, dann ist es leichter diese zu verletzen, als wenn man die syntaktisch Hürde überwinden muss. Ich meine, eine gewisse Hürde gibts ja in Python auch, nur verstehe ich eben solche Aussagen nicht, dass man das nicht oder kaum braucht usw ... Das ist ja dann eine Frage des Programmierstils und nicht unbedingt eine Frage guten Designs.
Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.
Und was die minimalen Hürden betrifft, die Kapselung zu verletzen, so ist das doch auch Ansichtssache. Es kann ja jeder so coden wie er möchte, nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.
Wenn ich ein Tür abschließe, dann kann ich die auch mit Gewalt öffnen, nur wenn sie abgeschlossen ist, kann eben nicht jeder Heini rein, der gerade mal zufällig davorsteht, und noch nicht mal weiß, was er da überhaupt soll.

Man kann doch nicht immer davon ausgehen, dass der Entwickler der Software zeit seines Lebens der einzige ist, der an dem Programm arbeitet und damit genau weiß, was er tunlichst unterlassen sollte.

[Darii]

Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.

Das kann man in Java eben nicht so einfach. In Python ist es kein Problem die Funktionsweise von Attributen zu ändern ohne das Interface zu verändern. Das geht in Java nicht.

Code: Alles auswählen

class Person:
    name = "Hans Mustermann"

p = Person()
p.name = "Max Müller"

# nun möchte man beim setzen des Attributs noch etwas machen

class Person:
    _name = "Hans Mustermann"

    @property
    def name(self):
        return self._name
    
    @name.setter
    def name(self, name)
        self._name = name
        self.anrede = "Herr"

# Das Interface nach außen ist gleich geblieben
# In Java müsste man name private machen und
# getter und setter einführen, das würde das Interface
# aber ändern.
p = Person()
p.name = "Max Müller"

nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.

Dagegen spricht ja auch nichts es geht den meisten auch nur damit, dass man nicht alles private machen muss "weil sich das halt so gehört" bei einem, von trivialen gettern hat auch niemand was.

[Leonidas]

Das sagt niemand, nur finde ich syntaktische Unterstützung nicht verwerflich und sie zu nutzen auch nicht.

Ja, stimmt. Gibt es aber nicht, also kann es wohl nicht verwerflich sein sie nicht zu nutzen, weil es gar nicht möglich ist in Python.

Wenn alles nur aus Konventionen besteht, dann ist es leichter diese zu verletzen, als wenn man die syntaktisch Hürde überwinden muss. Ich meine, eine gewisse Hürde gibts ja in Python auch, nur verstehe ich eben solche Aussagen nicht, dass man das nicht oder kaum braucht usw ...

Du meinst den Bodenstrich? Ja, ist eine kleine Hürde, aber wenn man Python programmiert, dann weiß man dass man ``_``-Attribute nur anfasst, wenn man weiß was man will. Es ist nun mal vieles simpler gemacht und so gesehen ist es auch nicht schwer in Java in der IDE einen Menüpunkt anzuklicken "hol mir das Attribut via Reflection".

Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.

In Java ist das nicht so üblich, aber angenommen das wäre so, dann würden sich die meisten Leute dabei doch auch nichts denken "ist halt so", ggf sogar "OOP ist eben so". Es hängt wohl ab, was man selbst gewöhnt ist und erwartet.

Ich habe vor paar Tagen dieses hübsche Zitat in comp.lang.python gefunden:

> Python *is* object-oriented, but it is not (as your definition suggests)
> object-fascist.  

I'd put it more mildly. Python is object oriented. The orientation is
there but the fanatism is gone.

Letztendlich ist der Mechanismus dass alles public ist in meinen Augen genauso gangbar. Bei realen Objekten ist es auch so dass man auf interna zugreifen muss, also ggf. das Auto zerlegt und womöglich kaputtmacht. Man muss eben selbst wissen, in wie weit man gehen will. So gesehen ist ``private`` genauso eine Konvention wie ``_``, in Java ist sie syntaktisch, in Python eher semantisch.

Es kann ja jeder so coden wie er möchte, nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.

Wenn er sich nicht dran hält, dann ist das sein Problem. Der Bodenstrich hat sich in der Community durchgesetzt, und wenn sich jemand nicht daran halten will ist das seine Entscheidung. Da muss man ihm nicht zusätzlich Steine in den Weg werfen.

Wenn ich ein Tür abschließe, dann kann ich die auch mit Gewalt öffnen, nur wenn sie abgeschlossen ist, kann eben nicht jeder Heini rein, der gerade mal zufällig davorsteht, und noch nicht mal weiß, was er da überhaupt soll.

``Tür._aufbrechen`` ist von der Sicherheit genauso wie ``private void aufbrechen``. Der Unterschied ist eigentlich nur die Einstellung des Programmierers. In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Bei uns vor dem Haus steht am Gehweg eine Schneeschaufel, den ganzen Winter über. Wenn jemand sie mitnehmen will, ist sie völlig ungeschützt gegen Diebstahl, lediglich über die Soziale Konvention, dass man fremde Sachen nicht einfach mitnimmt. Natürlich, man könnte sie anketten oder ins Haus tragen, aber es funktioniert so auch.

Bei den Attributen ist es noch besser, denn wenn jemand auf ``private`` Attribute zugreift ist das sein Problem, nicht meines. Ich habe gesagt auf was er zugreifen kann, wenn er darüber hinausgeht, nicht mein Problem. Also wie im Straßenverkehr. Wenn jemand mit seinem Porsche mit 100 durch die Stadt fährt, ist nicht der Hersteller daran schuld. Und eine auf technischem Wege erzwungene Geschwindigkeitsbegrenzung würde wohl auf Protest vieler Autofahrer stoßen.

'Tschuldige für die vielen mäßig passenden Vergleiche (das ist immer so das Problem). Vielleicht wirst du dann meinen Standpunkt verstehen - wenn nicht, dann ignorier sie einfach.

Man kann doch nicht immer davon ausgehen, dass der Entwickler der Software zeit seines Lebens der einzige ist, der an dem Programm arbeitet und damit genau weiß, was er tunlichst unterlassen sollte.

Ganz recht. Dafür gibt es ja sowohl in Python wie auch in anderen Sprachen Dokumentation, die über ein einfaches ``private``/``publich`` Schwarzweißsehen hinausgeht und erklärt wie man die API richtig nutzt (und Kommentare sowie ggf. noch andere Dokumente erklären die Implementierung).

[BlackJack]

Wenn man in Java einfach alles ``public`` macht, ist das nicht dasselbe wie in Python, weil man dann ja nicht mehr unterscheiden kann welches ``public`` Attribut man bedenkenlos benutzen darf und welches nicht. Was in Python eben durch den Unterstrich gekennzeichnet ist.

Wer auf Implementierungsdetails nur deswegen nicht zugreift, weil er es nicht machen kann, ist kein besonders guter Programmierer.

Und zumindest IMHO sind Kapselung und Zugriffsschutz zwei orthogonale Konzepte, die man zusammen nutzen kann, aber nicht muss. Solange man öffentliche Schnittstelle und Implementierungsdetails klar unterscheiden kann, braucht man keinen Zugriffsschutz um Kapselung zu betreiben.

Wer Interna verwendet, muss mit den möglichen Konsequenzen leben. Wer Interna nicht verwenden kann, weil Zugriffsschutz im Weg steht, muss unter *den* Konsequenzen manchmal leiden.

[nkoehring]

In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Schoen gesagt

[Marky]

Ja, stimmt. Gibt es aber nicht, also kann es wohl nicht verwerflich sein sie nicht zu nutzen, weil es gar nicht möglich ist in Python.

na ja, die __ Konvention geht ja schon ein wenig über die reine Syntax-Konvention hinaus. Auch wenn das auf Name-mangeling hinausläuft oder wie sich das nennt.
Ein Zugriff von außen mit der Attribut-Bezeichnung von innen ist auf das Objekt-Attribut nicht mehr direkt möglich. Das reicht mir doch schon

In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Schoen gesagt

Finde ich auch

... und ab wann wird/ist man mündig ? Wenn man die Fehler, vor denen einen Java angeblich schützt, nicht mehr macht?

Aber ich denke, ich habe jetzt ein paar Statements gelesen und konnte mir dadurch einen Eindruck zur Meinungsbildung verschaffen.
Schon mal Besten Dank.

Nachtrag:

'Tschuldige für die vielen mäßig passenden Vergleiche (das ist immer so das Problem). Vielleicht wirst du dann meinen Standpunkt verstehen - wenn nicht, dann ignorier sie einfach.

Kein Problem. Es geht mir übrigens nicht darum, Java gegenüber Python in den Himmel zu heben, sondern einfach die (andere) Sichtweise zu verstehen, wenn man mit Python arbeitet.

[Leonidas]

na ja, die __ Konvention geht ja schon ein wenig über die reine Syntax-Konvention hinaus. Auch wenn das auf Name-mangeling hinausläuft oder wie sich das nennt.
Ein Zugriff von außen mit der Attribut-Bezeichnung von innen ist auf das Objekt-Attribut nicht mehr direkt möglich. Das reicht mir doch schon

Achtung, wenn du Name Mangling als "private"-Mechanismus verwendest, wirst du auf Kritik stoßen. Dafür ist es nämlich weniger gedacht. Meist nimmt man für private ``_`` und lässt Mangling Mangling sein.

Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private.

Edit: Schöner Blogpost zu ``__``.

[Marky]

ok. ist "gebookmarked" ...

[bwbg]

Randbemerkung: C++, als typsichere Sprache, bietet ein Brecheisen für private Attribute etc. in ihrer Syntax an. Den allseits beliebten reinterpret_cast<New>(old).

So kann man ganz genüsslich in den Eingeweiden eines Objektes rumwühlen, vorausgesetzt, man kennt die Internas.

Schlussendlich - und das gilt nicht für Programmiersprachen alleine - gibt es keine absolute Sicherheit. Es ist sicherlich etwas gewöhnungsbedürftig, wenn man seitens der Programmiersprache mehr Verantwortung übertragen bekommt und nicht gleich entmündigt wird.

Grüße... Heiko

[Darii]

Naja, dafür ist es ja auch nicht gedacht. Wer z.B. ein Feld "password" private macht nur weil keiner ran soll hat was falsch verstanden.

[bwbg]

Naja, dafür ist es ja auch nicht gedacht. Wer z.B. ein Feld "password" private macht nur weil keiner ran soll hat was falsch verstanden.

Sinnhaftigkeit unterscheidet sich meist sehr oft von Machbarkeit - Mir ging es aber nicht um die Objektsicherheit was die Geheimhaltung des Inhaltes betrifft, sondern vielmehr die Objektsicherheit hinsichtlich der Manipulation von Interna.

Mir (in meiner hobbymäßig, oberflächlichen Beschäftigung mit C++) ist bislang noch kein Anwendungsfall untergekommen, einen reinterpret_cast zu verwenden - dynamic_cast und const_cast (gerade in Verbindung mit C-Libs) schon eher.

Das driftet jetzt aber doch etwas ab...

Grüße... Heiko

[PythonÜbernehmenSie]

Ich möchte mich in die Diskussion als bisher nur passiver Leser auch mal einbringen. Vielleicht teilt ja jemand meine augenscheinliche Vorliebe für klar strukturierte, aber etwas lange Sätze

Zu der Private/Public-Problematik fällt mir ein schönes Zitat ein, das ich in einem anderen Forum gelesen hab:

private schützt vor Murphy, nicht vor Macchiavelli.

Klar ist. dass ich (zumindest in einer Umgebung, die Zeigerarithmetik unterstützt) immer an private Attribute komme, wenn ich es wirklich will. Aber greife ich z.B. in C++ auf eine private Eigenschaft zu, erhalte ich eine Fehlermeldung des Compilers. Durch casten oder Zeigerspielereien komme ich wie gesagt natürlich an die Daten ran, aber da ist ein zunächst einmal gewissser Aufwand dabei. Die Konvention, _ als Präfix für privat gemeinte Attribute zu verwenden, wird dagegen nur durch die Disziplin des Verwenders der Klasse durchgesetzt - ein absichtliches Zugreifen auf ein solches Element ist also als solches erst nach näherer Analyse des Codes und gggf. Konsultation der Dokumentation zu ersehen.

Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind. Und das Aushebeln der Steuerung, welche Programmteile auf welche Attribute eines Objektes wie zugreifen dürfen und welche nicht, ist meines Erachtens bei einer Sprache, die (u.a.) das objektorientierte Programmierparadigma unterstützt, konzeptionell eher "schlecht".

Als ich mir das erste Mal Python angesehen habe, kam es mir deshalb auch unverständlich vor, dass es für diese Zugriffssteuerung in Python keine Unterstützung seitens der Sprache gibt.

[str1442]

Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind.

Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.

Wenn es einen höheren Aufwand gibt, dann sollte dieser auch mehr oder weniger klar und einfach sein und nicht aus irgendwelchen Hacks bestehen. Das Benutzen von irgendwelchen Pointer Spielereien oder #define private public kann man wohl kaum als einen "standarisierten" Weg zu beschreiben, oder?

[PythonÜbernehmenSie]

Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.

Die Sache mit _ ist eben keine Eigenschaft der Sprache, sondern eine Konvention, die der Programmierer der Klasse einhält - oder auch nicht. Es ist ein unverbindlicher Vorschlag, mehr nicht. Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.

Es geht mir nicht zwingend um die Auftrennung in private, protected und public - es geht um Zugriffssteuerung auf Objektklassenebene an sich. Sehr viele Sprachen benutzen dafür eben diese drei (teilweise auch mehr) Sichtbarkeitsbereiche, eventuell kombiniert mit spezifisc hen "Freundschaften", was sicher nicht der Weisheit letzter Schluss ist, aber es funktioniert halbwegs! Python aber verfügt über keinen solchen Mechanismus. Mein Eindruck, der in diesem Thread durchaus bestätigt wird, ist der, dass im Alltag so etwas aber durchaus benötigt wird - deswegen wird der Benennungsvorschlag mit _ empfohlen.

Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.

[Hyperion]

Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.

Also ich denke man sollte gerade eine gute Dokumentation erwarten können! Was nützt Dir ein Modul ohne Doku? Nichts! Aber das ist doch in jeder Sprache so

Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.

Also ich habe das noch nie benutzt - mag aber sein, dass ich nicht grad nen Python-Gott bin und meine Erfahrung da nicht zählt