C++ Warum private?

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.

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...

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

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.

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.

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.

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.