Wozu braucht man private Methoden oder Variablen (Datenkappselung)?

[deepthroat]

Hi.

Da hast du natürlich recht. Sicherlich könnte man jetzt gegenargumentieren und sagen, dass mögliche Fehler mit dem Unit-Testing aufgedeckt werden.

Welche Software hat 100% Unit-Test Abdeckung? ;-]

Das ist wieder so eine Sache... Wozu brauche ich in einem Programm read-only Attribute / Variablen? Wenn ich eh nicht darauf schreibend zugreife, dann brauche ich die Variable auch nicht read-only zu deklarieren. Ich bin ja der jenige, der beschlossen hat, dass ich nur lesend auf die Variable zugreife. Zur Not benenne ich die Variable mit "_ro" als Postfix, rein zur Erinnerung.

Um (wie Vereth auch schon sagte) Inkonsistenzen im System zu unterbinden. Warum sollte ich es riskieren das ein Programmteil (auf den ich keinen Einfluss habe) den Wert eines Attributes ändert (_ro Suffix hin oder her)?

Das ist natürlich der "klassische" Grund, der auch mir eingetrichtert wurde. Was meinst du denn genau mit öffentlich? Ich glaube, wir sind uns darüber einig, dass ein Anwender (also die Öffentlichkeit) absolut nichts sieht, was im Quelltext geschrieben steht. Er kann auch nicht einfach mal eben private Methoden aufrufen. Und dann gibt es noch den / die Programmierer. Wieso sollten die denn nicht sehen dürfen, was in der Instanz einer Klasse vorsich geht?

Es geht nicht darum etwas zu dürfen. Wie gesagt kann man wohl kaum verhindern das jemand irgendetwas im Quellcode herumpfuscht. Aber nicht öffentliche Attribute / Methoden brauchen einen anderen Programmierer nicht zu interessieren. Man bietet eine öffentliche Schnittstelle und fertig. Die öffentliche Schnittstelle sollte man nie ändern, da andere Programmteile natürlich davon abhängen (könnten). Wenn ich sauber gearbeitet habe kann ich den Typ der privaten Attribute jederzeit ändern. D.h. ich bin frei in der Entscheidung etwas an der internen Implementierung zu ändern ohne das 3 andere Entwickler mir auf's Dach steigen weil ihre Module nicht mehr kompilieren oder laufen.

Hast du denn eigentlich mal ausprobiert was passiert wenn du aus einem Attribut eine read-only Property machst so wie in Beitrag #6? Du änderst hier das ABI - d.h. das Modul ist nicht mehr kompatibel zur alten Version und jedes abhängige Modul bzw. Programm muss neu kompiliert werden. Nur weil es syntaktisch gleich aussieht, ist es dennoch ein ganz anderes paar Schuhe.

Gruß

 

[Vereth]

@port29: Solange du deinen Programmcode nur für dich schreibst und ihn nicht anderen zugänglich machen willst/brauchst, kannst du selbstverständlich ganz deinem persönlichen Stil frönen; Dali hat schließlich auch anders gemalt als Dürer. Sobald du jedoch deine Klassen/Programme anderen Leuten zur Verfügung stellen möchtest, solltest die dich der Befolgung gewisser stilistischer Konventionen befleißigen, um die Lesbarkeit zu erhöhen. Es gehört nicht zum guten Ton, die Nachvollziehbarkeit durch fehlende Strukturierung und spät zu erkennende Redundanzen künstlich zu erschweren.

 

[Neither]

Hallo Leute,

seitdem ich nun seit zwei Jahren mit Ruby bzw. mit RoR programmiere, frage ich mich, wozu private Methoden und Variablen in C* oder Java tatsächlich gut sind.
...
Ich bin selbst seit 10 Jahren C++ bzw. seit 5 Jahren C# Programmierer. Die Datenkappslung habe ich bisher noch nie in Frage gestellt, bis jetzt. Denn momentan sehe ich keinen Grund dafür. Wie seht ihr das?

Peter Lavin hat es in einem seiner Bücher sehr gut erläutert: Es geht nicht nur um die Konsistenz von Daten oder darum Code vor anderen zu verbergen, vielmehr ist die Deklaration mit private, public oder protected auch eine wichtige, aber dennoch einfache Art der Dokumentation - nicht nur bei der Arbeit innerhalb von Teams, sondern auch für den einzelnen Entwickler selbst, der sich nach Monaten der Abstinenz wieder einmal mit dem eigenen Programm auseinandersetzen "darf".

Natürlich kann ein DAU je nach System und Aufbau der Programme versuchen den Code trotzdem zu ändern. Wenn er aber nicht wirklich absolut dämlich ist (jaja...) wird er sich bei der Deklaration private oder protected zumindest denken können, dass er damit in der Gefahr ist eine interne Logik zu umgehen, die vielleicht sogar nicht erkennbare Abhängigkeiten verbirgt.

Ich denke die Hemmschwelle ist bei (Skript-)Sprachen wie PHP, Ruby oder Python auch geringer, als bei Sprachen die kompiliert werden und bei denen dann doch häufiger fremde Klassen, Bibliotheken oder dlls eingebunden werden. Oft ist dort der Umfang der fremden Komponenten dort auch wesentlich größer, als dass man mal eben im Quellcode "rumpfuscht".

Andererseits denke ich auch, dass man da nicht allzu päpstlich sein sollte

 

[Ringelsocke]

Mir war bisher nie bewusst, dass man dieses Konzept in Frage stellen kann...
Ein Klasse sollte nach AUSSEN immer nur die Properties und Funktionen zur Verfügung stellen, die ein Anwender der Klasse verwenden dürfen soll. Was das genau ist, dass muss man beim Entwurf/Planen der Klasse (was jeder gute Entwickler tun sollte) festlegen. Und zu diesem Entwurf gehört nun mal auch, dass man festlegt, was der Anwender NICHT tun darf. Um ein ganz minimales Beispiel zu nennen, du hast ne Klasse User mit Vorname und Nachname. Du könntest nun natürlich das ohne Properties machen und direkt drauf schreiben lassen. Aber wie stellst du dann sicher, dass der Anwender keinen Mist einträgt? Oder wenn du nur bestimmte Namen zulassen willst? Das geht nur, wenn du private Variablen erstellst und das Setzen über den Setter geschieht, der dann überprüft, ob der Name überhaupt gültig ist. Das ist aber nur ein ganz einfaches Beispiel.

Es gibt aber weitere Vorteile:

- Ist alles public, dann sieht der Anwender viel mehr Funktionen, die meisten davon wahrscheinlich Hilfsfunktionen die er nicht nutzen soll oder braucht, das verwirrt und macht die API unnötig kompliziert. Man will es dem Anwender ja möglichst einfach machen und ihm das Leben nicht unnötig schwer machen. Zudem könnte ein Anwender, wenn er ungünstig irgendwelche Funktionen aufruf, das Objekt irgdenwie in einen ungültigen Zustand bringen. Willst du das alles abfangen? Und vor allem wo, denn die Problem müssen sich ja nicht zwingend unmittelbar zeigen (wenn der Anwender zum Beispiel einfach eine Variable auf null setzen und viel später erst fliegt ne Exception) Ist doch viel einfacher für dich als Entwickler wenn du es gleich von vorne herein sperrst, so dass er die Funktionen die er nicht nutzen soll auch garnicht nutzen kann...oder trifft der nächste Punkt zu?

- Wie du gesagt hast, wenn er was macht was er nicht soll, dann fliegen halt Exceptions...damit machst du es dir sehr einfach, läuft was schief, dann willst du die Schuld von dir abwälzen und auf den Anwender abschieben, er hätte ja die Funktion nicht verwenden sollen. In einer guten Bibliothek kennzeichnen sich Funktionen, die der Anwender nie-nicht verwenden soll, dadurch, dass er sie von vorne herein garnicht aufrufen kann, weil sie eben private ist...und der nächste Punkt schließt sich gleich an:

- klar muss der Anwender nicht ein "DAU" sein...aber auch einem fähigen Anwender muss man doch das Leben nicht unnötig schwer machen in dem Sinne, dass er sich durch zig Dokumentationen und APIs (die dann DU schreiben musst) wälzen muss um zu wissen, welche Funktionen für ihn gedacht sind und welche nicht? Oder würdest du verlangen, dass sich ein Anwender durch deinen Quellcode wühlt, um zu begreifen, was er darf und was er besser lassen sollte? Abgesehen davon, dass unter diesen Umständen die meisten Leute, die nicht gerade Programmier-DAUs sind, deinen Code garnicht verwenden sondern lieber was eigenes schreiben, würde jeder der Ahnung von Softwarequalität hat diese Philosophie mit mangelhaft bewerten. Also zertifiziet bekommst du auf diese Art und Weise zu Recht null.

- Wenn du eine Klasse "PizzaBäcker" hast mit einer Liste Zutaten und der Funktion BackePizza(), dann soll vielleicht der Anwender garnicht wissen dürfen, was denn in der Zutaten-Liste ist, oder welche Unterschritte notwendig sind um die Pizza zu backen...er soll einfach nur das Ergebnis bekommen. Oder noch schlimmer, wenn du eine Art Shop hast mit einer Artikelverwaltung, stell dir mal vor, ein Anwender könnte den Preis eines Artikels einfach so ändern...

Des weiteren gehst du immer davon aus, dass andere den Quellcode editieren können...ich weiß nicht an welchen Projekten du gearbeitest hast, aber in den Projekten in denen ich arbeite hält man die abgeschlossenen Dlls möglichst klein (und wiederverwendbar), nach außen gibt es nur klar definierte Schnittstellen (müssen nicht mal unbedingt Interfaces sein). Und in Dlls kann niemand so einfach rumeditieren, die verwendet man nur in anderen Projekten. Das muss man auch garnicht, wenn man von vorne herein geplant hat, was ein Anwender mit einer Klasse machen darf.

gruß
Ringelsocke