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!
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? 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.
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.