Properties und Getters

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
bwbg
User
Beiträge: 370
Registriert: Mittwoch 23. Januar 2008, 13:35

Beitragvon bwbg » Dienstag 3. Februar 2009, 13:54

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 :wink: - 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
"Du bist der Messias! Und ich muss es wissen, denn ich bin schon einigen gefolgt!"
PythonÜbernehmenSie
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 20:54

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 :wink:

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.
Benutzeravatar
str1442
User
Beiträge: 520
Registriert: Samstag 31. Mai 2008, 21:13

Beitragvon str1442 » Samstag 7. Februar 2009, 21:33

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
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 22:40

str1442 hat geschrieben: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.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Samstag 7. Februar 2009, 22:46

PythonÜbernehmenSie hat geschrieben: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 ;-)
PythonÜbernehmenSie
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 22:52

Hyperion hat geschrieben:[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 mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken. Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...

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 ;-)


Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Samstag 7. Februar 2009, 23:01

PythonÜbernehmenSie hat geschrieben:Wenn mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken.

ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)
Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...

Also ich nutze nicht jedes beliebige Projekt, sondern eben die, die ich geeignet finde. Für das "geeignet"-Prädikat sind die Doku und ggf. auch Tutorials für mich durchaus eines der wichtigsten Kriterien!
Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.

Also das ist doch nun irgend wie platt: "Wenn alle aus dem Fenster springen, muss das ja gut sein!" Ok, weniger überspitzt: Python hat ja auch Dinge, die andere Sprachen nicht bieten. Sind die dann in den Punkten auch "schwach" designt? Wenn das so wäre und man diese "MIsstände" beseitigen müßte, würde das schließlich auf eine Universelle Sprache zusteuern ... so eine Art "Volksprogrammiersprache" :-D SCNR

Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!
PythonÜbernehmenSie
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 23:17

Hyperion hat geschrieben:ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)


Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.

Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!


Das würde ich nicht sagen. Ich sage, es gibt eine gewisse Anzahl an Programmierparadigmen, die natürlich recht abstrakt sind. Diese Paraidgmen werden dann in Sprachen auf verschiedene Art und Weise umgesetzt, eine Sprache wie Python setzt dabei mehrere Paradigmen (z.B. objektorienierte, prozedurale, funktionale) um. In dieser Diskussion geht es um das objektorienierte Paradigma. Dieses wird in Python durch den Einsatz von Klassen ermöglicht, in vielen anderen Sprachen (z.B. C++, Java, C#, Ruby) auch. In diesen Sprachen besitzen Klassen vor allem so Elemente wie Attribute, Methoden und Operatoren, Vererbung und eben auch Zugriffsschutz durch Sichtbarkeit. Python verfügt über die ersten drei, aber eben nicht über letzteres.

Soll heißen: Obwohl im Bereich der objektorientierten Programmierung eine starke Gemeinsamkeit mit anderen Sprachen herrscht, fehlt die Sichtbarkeitssteuerung.
Das ist ja zusammengefasst die Ausgangssituation.

Die Frage ist jetzt:
Braucht man diese Sichtbarkeitssteuerung und wenn ja, ist es ein Nachteil, dass Python so etwas nicht hat?
Benutzeravatar
str1442
User
Beiträge: 520
Registriert: Samstag 31. Mai 2008, 21:13

Beitragvon str1442 » Samstag 7. Februar 2009, 23:31

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.


Und in Java, C++ etc pp schreibt sich das "private" magisch vor die Variablen? Die ganze private, protected, public Geschichte ist nichts Essenzielles. Ein Programm funktioniert auch ohne das Zeug recht gut, egal in welcher Sprache. Warum es also "hart" (also syntaktisch) erzwingen? Und auf "_" wird sicherlich in jedem guten Tutorial hingewiesen. Aber ich finde auch Minimalismus toll.

Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten.


Worauf verlassen? Das das Teil keiner anfassen kann? Wo ist eigentlich das Problem? Wenn jemand das nicht (doppelte Verneinung :D) tut, ist das schlicht sein Problem. Entweder er weiß, was er tut, oder es kracht. Und jetzt erklär mir doch bitte noch, warum du in C++ *ohne* Dokumentation mit deinen Pointer Tricks mit pseudoprivaten Variablen besser dran bist als in Python ohne Dokumentation und mit "_".
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Samstag 7. Februar 2009, 23:36

PythonÜbernehmenSie hat geschrieben:Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.

Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!
PythonÜbernehmenSie
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 23:37

Stellvertretend für den ganzen Post beantworte ich nur diesen Satz:
str1442 hat geschrieben:Und jetzt erklär mir doch bitte noch, warum du in C++ *ohne* Dokumentation mit deinen Pointer Tricks mit pseudoprivaten Variablen besser dran bist als in Python ohne Dokumentation und mit "_".



Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.
Greife ich in C++ auf ein privates Objektattribut zu, gibt es dagegen einen Compilerfehler.
PythonÜbernehmenSie
User
Beiträge: 10
Registriert: Dienstag 14. Oktober 2008, 18:50

Beitragvon PythonÜbernehmenSie » Samstag 7. Februar 2009, 23:39

Hyperion hat geschrieben:Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!


Eben nicht:

- "private" ist ein Sprachelement, das verbindlich ist.
- "_" als Namensteil ist lediglich eine unverbindliche Empfehlung.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Samstag 7. Februar 2009, 23:47

PythonÜbernehmenSie hat geschrieben:
Hyperion hat geschrieben:Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!


Eben nicht:

- "private" ist ein Sprachelement, das verbindlich ist.
- "_" als Namensteil ist lediglich eine unverbindliche Empfehlung.

Ja aber der Programmierer muss sich doch in beiden Fällen damit auseinandersetzen! Ich sehe da Dein Problem nicht ganz.

Ich kann in Java doch auch alles public deklarieren - wo ist dann da der Vorteil, dass das ganze syntaktisch ist? So oder so muss sich der Entwickler dazu "bereit erklären", interne Strukturen auch vernünftig zu kennzeichnen.

Und wie Du ja auch schon geschrieben hast, ist eine gute Benennung von Methoden und Funktionen eben Gold wert!
Benutzeravatar
str1442
User
Beiträge: 520
Registriert: Samstag 31. Mai 2008, 21:13

Beitragvon str1442 » Samstag 7. Februar 2009, 23:48

Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.
Greife ich in C++ auf ein privates Objektattribut zu, gibt es dagegen einen Compilerfehler.


Und schlimmstenfalls hatt in C++ jemand statt private durchweg public benutzt und du erkennst es auch gar nicht. Das war mein Punkt mit "magisch". Es liegt immer am Programmierer. "_" wird mit an Sicherheit grenzender Wahrscheinlichkeit nicht weniger oft empfohlen wie private in C++, höchstens erst später.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7472
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Samstag 7. Februar 2009, 23:53

PythonÜbernehmenSie hat geschrieben:Greife ich in Python auf ein privates Objektattribut zu, sehe ich es bestenfalls am Namen; schlimmstenfalls gar nicht.

Was ist daran so schlimm? Was sagt Dir denn das "private" in anderen Sprachen, was Dir in Python "fehlt"?

In Java musst Du eben einen getter benutzen, um an den Wert des Attributes zu gelangen. Schön. Das kann ich in Python per property ebenfalls realisieren. D.h. der Zugriff ist gekapselt, ohne dass Du das merkst.

Die Gefahr die Du beschreibst ist doch damit genauso gut gebannt, wie bei C++ / Java!

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder