Wozu braucht man private Methoden oder Variablen (Datenkappselung)?

[port29]

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 habe mir auch den Artikel zur Datenkappslung bei Wikipedia durchgelesen, konnte aber dort auch keine richtigen Vorteile finden, außer dass man vielleicht das Innenleben einer Klasse geheimhalten möchte. Für mich persönlich steht eins fest: Programmierer sind nicht dumm. Wieso sollte man ihnen deshalb den Zugriff auf Variablen untersagen? Und wenn sie den Zugriff brauchen? Dann wird die private Variable einfach schnell zur public bzw. get/set Funktionen werden einfach reingesetzt. Da kann man sich ja eigentlich gleich die Mühe sparen und von Vorne rein alles public deklarieren.

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?

 

[Parantatatam]

Ich programmiere zwar hauptsächlich in PHP, aber auch da gibt es für die Datenkappslung die drei Methodenarten: private, protected und public. Der Punkt ist, dass man teilweise auch Sachen programmiert, die später ein anderer Entwickler (oder manchmal auch ein DAU) verwendet. Wenn der nun ausversehen eine mit private gekennzeichnete Methode aufruft, dann sollte das einen Fehler erzeugen und ihm somit signalisieren, dass das, was er gerade versucht, nicht möglich ist. Ansonsten kann es auch dem Programmierer selbst passieren, dass er irgendwann nach einer gewissen Zeit das Skript vor lauter Zeilen nicht mehr sieht und er dann vielleicht selber etwas versucht, was nicht sein soll. Ich meine, dass die Datenkappslung letztendlich nur eine Hilfe für den Programmierer ist.

 

[port29]

Ich programmiere zwar hauptsächlich in PHP, aber auch da gibt es für die Datenkappslung die drei Methodenarten: private, protected und public. Der Punkt ist, dass man teilweise auch Sachen programmiert, die später ein anderer Entwickler (oder manchmal auch ein DAU) verwendet. Wenn der nun ausversehen eine mit private gekennzeichnete Methode aufruft, dann sollte das einen Fehler erzeugen und ihm somit signalisieren, dass das, was er gerade versucht, nicht möglich ist.

Da stellen sich mir zwei Fragen:
- Wieso sollte das, was er vorhat, denn nicht möglich sein? Wenn es wirklich nicht möglich ist, wird schon eine andere Exception fliegen.
- Was macht der (DAU) Programmierer, wenn eine Methode privat ist? Er geht in den Quelltext und deklariert die als public.

 

[medieninf]

Hallo,

Datenkapselung ist u.a. wichtig wenn du die interne Implemenation änderst, nach außen jedoch konsistent bleiben willst.

Bsp.

class Person {

private String name = "Hans Wurst";

public String getName() { return name; }
}

Jeder Nutzt nun die Methode getName. Dann fällt dir ein man sollte das in private String vorname ="Hans"; und private String nachname ="Wurst" aufteilen. Gibst du halt return vorname+nachname zurück. Der Code der deinen Code aufruftt ändert sich nicht. Kann weiter getName aufrufen. Hättest du im Code direkt auf Person.name zugegriffen würde das nicht mehr funktionieren, da ja dort nur noch der nachname steht

 

[Parantatatam]

Zu den privaten Methoden: ich verwende private Methoden beispielsweise, wenn ich einen Algorithmus in verschiedenen anderen Methoden dieser Klasse verwenden will, aber eben nicht jedes mal den Code kopieren will, was auch recht hirnrissig wäre. Da könnte ich auch andere Funktionen verwenden, sicherlich, aber wenn dieser Algorithmus nur in dieser Klasse verwendet wird, warum sollte ich es dann in eine Funktion schreiben, die sonst niemand verwenden kann? Und zu den DAUs: gut, da hast du recht, aber wenn man wirklich nur jemanden hat, der ein Framework verwendet, aber nichts genaueres darüber weiß, der wird dadurch erstmal zurückschrecken.

 

[port29]

Jeder Nutzt nun die Methode getName. Dann fällt dir ein man sollte das in private String vorname ="Hans"; und private String nachname ="Wurst" aufteilen. Gibst du halt return vorname+nachname zurück. Der Code der deinen Code aufruftt ändert sich nicht. Kann weiter getName aufrufen. Hättest du im Code direkt auf Person.name zugegriffen würde das nicht mehr funktionieren, da ja dort nur noch der nachname steht

Das ist kein Argument dafür:

        public virtual String Name {
            get { return Vorname + Nachname; }

        }

....

String bla = instanz.Name

Wie du siehst, habe ich hier aus einer Variable ein Attribut erstellt, bei dem ich den Ausgabestring dynamisch gestalten kann.

 

[medieninf]

Weiteres Argument:

du kannst durch getter/setter Methoden den Zugriff auf Attribute "kanalisieren" und bsp. bestimmte Dinge abfragen. Bsp. könnte man so verhindern einer Variablen einen negativen Wert zuzuweisen...

BTW:

Das erste ist durchaus auch ein Argument. Dein "dynamisches" vorgehen lässt sich möglicherweise nicht in jeder Programmiersprache realisieren...

 

[deepthroat]

Hi.

Das ist kein Argument dafür:

Doch, ist es. Zumindest in C++ und Java.

- Was macht der (DAU) Programmierer, wenn eine Methode privat ist? Er geht in den Quelltext und deklariert die als public.

Und auch ein DAU kann nicht so einfach die Zugriffslevel modifizieren ohne ein Bibliothek neu zu erstellen. Und selbst wenn ein DAU dann soetwas macht kann man ihn wohl schlecht davon abhalten.

- Wieso sollte das, was er vorhat, denn nicht möglich sein? Wenn es wirklich nicht möglich ist, wird schon eine andere Exception fliegen.

Kontrolle zur Kompilierzeit ist besser als zur Laufzeit.

Sinnvoll sind private / protected Attribute außerdem um read-only Attribute zu realisieren (wenn die Sprache keine read-only Properties unterstützt).

Manche Attribute werden auch nur intern in der Klasse verwendet (zum Caching o.ä.), diese sollten eben von aussen nicht zugreifbar sein. Warum sollte man (öffentlich) die Hosen runterlassen wenn es nicht notwendig ist? ^^

Außerdem schränken private / protected Attribute die Komplexität ein. Es gibt nicht unzählige Stellen wo auf die Attribute zugegriffen werden kann, was sich beim Debugging bezahlt macht.

Gruß

 

[Vereth]

• Manche Attribute werden nur intern verwendet. Um die Datenkonsistenz (ganz wichtiges Prinzip!) zu wahren, sollte der Zugriff von außen verhindert werden.
• Manchmal rufe ich innerhalb einer Methode wiederum Methoden desselben Objektes auf; dafür splitte ich die aufzurufende Methode auf in eine private-Methode ohne aufwändige Parametertests (denn ich mache keine Fehler 8) und eine public-Methode, die nur die Parameter überprüft und dann, wenn diese ok sind, die private-Methode aufruft (denn beim DAU sind Fehler an der Tagesordnung).
• Manche Methoden deklariere ich als private, weil diese Funktionalitäten zur Verfügung stellen, die mit der eigentlichen Klasse nichts zu tun hat, aber nützliche Dienste/Vorarbeiten für andere Methoden leisten, eventuell sogar für mehrere.
• Meine IDE soll mich beim Auto-Vervollständigen nicht mit Sachen zumüllen, die sowieso keiner braucht.

 

[port29]

Ich weiß momentan irgendwie nicht, wieso wir uns über DAU Programmierer unterhalten. Ich gehe eigentlich davon aus, dass die Leute, die an einem Projekt arbeiten, schon eine gewisse Ahnung haben, was die machen. Ich will jetzt nicht sagen, dass private Methoden etwas falsches sind (denn schließlich habe auch ich 10 Jahre auf diese Art programmiert), aber momentan hinterfrage ich etwas das Konzept und würde es mit euch gerne diskutieren.

Kontrolle zur Kompilierzeit ist besser als zur Laufzeit.

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

Sinnvoll sind private / protected Attribute außerdem um read-only Attribute zu realisieren (wenn die Sprache keine read-only Properties unterstützt).

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.

Manche Attribute werden auch nur intern in der Klasse verwendet (zum Caching o.ä.), diese sollten eben von aussen nicht zugreifbar sein. Warum sollte man (öffentlich) die Hosen runterlassen wenn es nicht notwendig ist? ^^

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?

@Vereth
Ich sehe in deinem Posting keinen Grund gegen die Deklarierung von Attributen als public. Und mal ganz ehrlich: Rails bzw. RoR Anwendungen entwickle ich mit Textmate. Ein simpler Editor, der kein Intellisense oder Verfollständigungen in der Art von Visual Studio bietet. Am Anfang war es auch für mich schwierig, aber wenn du diese Hilfestellung nicht hast, konzentrierst du dich wirklich auf die Quellcodes, die du schreibst. Ich hab es früher in C# / Java auch immer so gemacht, dass ich den Instanznamen mit einem Punkt am Ende hingeschrieben habe, dann etwas gewartet habe, bis sich das Vorschlagsmenü aufgerufen hat und dann das richtige Kommando zuende getippt habe. In Textmate tippe ich entweder alles bis zum Ende durch oder drücke die Escape Taste (verfollständigt die Zeichenkette)