Forum: PC-Programmierung C++ Warum private?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernhard Stock (Gast)


Lesenswert?

Hallo guten Tag,

wenn man den Source-Code von einer C Klasse hat, kann man ja überall 
darauf zugreifen.
Wenn Variablen oder Methoden  private sind, ist es möglich sie mit get 
und set zu  aufzurufen, sofern sie nicht auch private sind.

Also dient private dazu anderen Nutzer damit klar zu machen, welche 
Member genutzt werden sollten und welche nicht.

So kann eine Übersicht beibehalten werden und Fehlverhalten besser 
zurückführbar sein.

Aber grundsätzlich kann doch jeder die Klassen umschreiben wie er möchte 
oder nicht?

Danke sehr!

von Programmierer (Gast)


Lesenswert?

Bernhard Stock schrieb:
> Aber grundsätzlich kann doch jeder die Klassen umschreiben wie er möchte
> oder nicht?

Das ist kein Sicherheitsfeature, welches wirklich den Zugriff verhindern 
soll, sondern eher eine "technische Erinnerung". Der Nutzer der Klasse 
soll vor sich selbst geschützt werden, damit er nicht (versehentlich) 
interne Daten eines Objekts durcheinander bringt, oder seinen Code von 
Interna abhängig macht, welche sich gerne mal ändern können. Wer die 
private-Deklaration umgeht/ändert und dann Probleme bekommt ist selbst 
schuld.

von Bernhard Stock (Gast)


Lesenswert?

Programmierer schrieb:
> Probleme bekommt ist selbst
> schuld.

Danke sehr :)

Gibt es eigentlich solche Sicherheitsfeatures? Also die mit einem 
Passwort arbeiten oder ähnliches?
Also natürlich so, dass es Sinn macht.. Kann ja sein...

von Programmierer (Gast)


Lesenswert?

Bernhard Stock schrieb:
> Gibt es eigentlich solche Sicherheitsfeatures? Also die mit einem
> Passwort arbeiten oder ähnliches?

Nicht innerhalb eines Programms/Prozesses. Selbst in "managed" Sprachen 
wie Java oder C# kannst du über Umwege (Reflection oder JNI) auf alles 
zugreifen, was im Prozess passiert, in C und C++ sowieso.

Solche Sicherheitsbarrieren werden praktisch immer zwischen Prozessen 
oder ganzen Computern implementiert. Wenn du z.B. auf einen SQL-Server 
oder ein REST-API zugreifst, kann der Server ein Passwort verlangen. Das 
kann der Client nicht leicht umgehen, weil er keinen Zugriff zum Prozess 
der Server-Software hat.

Wer physischen Zugriff auf den Computer oder Betriebssystem des Servers 
hat, kann das aber umgehen indem er im Adressraum des Servers herum 
pfuscht, ähnlich wie Cracks zum Kopierschutz aushebeln.

Ganz interessant ist das unter Android, dort können Apps über Binder 
(eine Art RPC) Funktionen in anderen Apps oder System-Diensten aufrufen, 
welche das aber verweigern können, u.a. abhängig von den Permissions der 
App. Das lässt sich nicht umgehen außer durch rooten (oder eventuelle 
Bugs im System). Dazu kommt der Schutz durch SELinux, bei dem der Kernel 
Zugriffe auf Systemressourcen steuert (u.a. Dateien, Sockets).

von Michael B. (laberkopp)


Lesenswert?

Bernhard Stock schrieb:
> Aber grundsätzlich kann doch jeder die Klassen umschreiben wie er möchte
> oder nicht?

Wenn er den Source-Code hat, schon.

Wenn aber einer die Implementierung einer Klasse umschreiben will, 
effizienter machen mit neuem Algorithmus oder basierend auf anderen 
internem Unterbau, dann darf er private Dinge einfach ändern, muss sich 
keine Gedanken machen ob die irgendwoanders verwendet werden und er 
dadurch vielleicht Änderungen erzwingt damit alles wieder läuft, sondern 
private ist eben seins, privat, unter seiner Kontrolle.

Public Dinge lässt er tunlichst so wie sie waren, denn die sind 
Interface.

von J. S. (jojos)


Lesenswert?

Bevor man aus Paranoia anfängt getter/setter dem Performancegott zu 
opfern, sollte man sich genau ansehen (Profiler) ob solche Änderungen 
wirklich nötig sind. In get/set können z.B. auch Funktionen aufgerufen 
werden und das würde man durch direkten Zugriff kaputt machen.

von MaWin O. (mawin_original)


Lesenswert?

Bernhard Stock schrieb:
> Also dient private dazu anderen Nutzer damit klar zu machen, welche
> Member genutzt werden sollten und welche nicht.

> Aber grundsätzlich kann doch jeder die Klassen umschreiben wie er möchte
> oder nicht?

Private, protected und public sind Beschränkungen/Beschreibungen auf 
Typebene.
Du beschreibst damit, wie innerhalb des C++-Typsystems auf die Member 
zugegriffen werden kann und wie nicht.

Selbstverständlich hindert es nicht den Programmierer daran diese 
Beschränkung wieder zu entfernen und aus einem private ein public zu 
machen.

Das ist ja genau das gleiche, wie wenn deine Variable Hugo den Typ int 
hat. Selbstverständlich kann der Programmierer den Typ wieder ändern. 
Aber solange der Typ so ist, wie er ist, gelten die Regeln dieses Typs.

Bernhard Stock schrieb:
> Gibt es eigentlich solche Sicherheitsfeatures

Ja, aber das hat mit der Programmiersprache dann nichts mehr zu tun.
Beispielsweise wird im Betriebssystem ja festgelegt, wie dein Programm 
mit anderen Programmen kommunizieren darf. Ein Programm darf/kann ja 
nicht einfach so in den Speicher von anderen Programmen hineingreifen. 
Das ist also auch so etwas wie "private". Aber durch ganz anderere 
Mechanismen und auf ganz anderer Ebene durchgesetzt.
Dein private in C++ wird vom C++-Compiler erzwungen.
Die Zugriffe auf unerlaubte Speicher von z.B. anderen Programmen werden 
vom Betriebssystem und von der Hardware beschränkt.

von C++ Haxxor (Gast)


Lesenswert?

1
#define private public
2
#include <KlassenHeader>
3
...

von MaWin O. (mawin_original)


Lesenswert?

C++ Haxxor schrieb:
> #define private public
> #include <KlassenHeader>

Das mag vielleicht mit vielen Compilern funktionieren, aber garantiert 
ist das nicht.
Der Compiler könnte z.B. für private-Symbole ein anderes Name-mangling 
verwenden, als für public-Symbole.
Du begibst dich da mindestens einmal auf den Weg des 
implementation-defined.

von PittyJ (Gast)


Lesenswert?

Bernhard Stock schrieb:
> Aber grundsätzlich kann doch jeder die Klassen umschreiben wie er möchte
> oder nicht?

Ja.
Und C hat diese wunderbaren Pointer. Damit kannst du alles an beliebige 
Adressen schreiben, ohne dich an Klassen, Structs oder Arrays zu halten.

Du nimmst aber trotzdem eine Klasse, weil es für dich klarer ist und die 
Sache für einen Menschen vereinfacht.

von jetztnicht (Gast)


Lesenswert?

Mit private werden direktzugriffe verhindert. Wird spaghetticode 
verhindert. Bei einem 100 zeiligen Programm ist das unwichtig. Bei 100k 
Zeilen ist jede Woche Debugging sehr teuer. Deswegen bieten moderne 
Sprachen dieses Feature.

von Thomas-jhfd (Gast)


Lesenswert?

Es ist ja vor allem ein Komfort für mich als Anwender von 
Klassenbibliotheken.
Was interessiert mich, wie das implementiert ist?
Ich möchte nur die Schnittstelle sehen und nicht mit internen Details 
belästigt werden.
Alleine schon das IntelliSense meiner IDE würde mich völlig überfordern, 
wenn mir alle interne Properties / Methoden gelistet werden, die von 
außen gar nicht sinnvoll nutzbar sind.

Umgekehrt möchte ich als Entwickler solcher Libs meinen Anwendern auch 
eine gute Usability liefern.
Da soll dann z.B. ein Kaufmann per Excel-VBA Daten von einem Webservice 
abfragen ohne jemals auch nur was von GET, POST oder JSON gehört zu 
haben.
Mit einem guten Interface geht das ohne diese Kenntnisse.

Klar, wenn du als einzelner Entwickler an einem kleinen Projekt 
arbeitest musst du dir über die API nicht ganz so große Gedanken machen. 
Aber zumindest im Hinterkopf haben sollte man das immer.

von Noch ein Kommentar (Gast)


Lesenswert?

> Wer die private-Deklaration umgeht/ändert und dann Probleme bekommt
> ist selbst schuld.

Nur leider bekommt jemand anders die Probleme.

Die Scrum-Teams frickeln einfach kreuz und quer irgendwelche Getter und 
Setter dran. Finden es ganz normal, dass sie da selbst nicht mehr 
durchblicken. Die merken nicht mal, dass sie ein Problem haben.

Die Probleme bekommen entweder Support und Anwender oder die Entwickler, 
die den Spagettihaufen wieder entwirren müssen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.