friend-Deklarationen Anzeiche für unsauberes Design
-
Mal eine Frage, sind friend-Deklarationen/Anweisungen eigentlich ein Anzeiche für unsauberes Design? Im Prinzip verletzt man ja damit das Daten-Kapselungs-Konzept, auf der anderen Seite ist es manchmal nötig, weil man ja nicht hunderte von Routinen implementieren will, die nichts weiter machen, als ein member zu setzen bzw. zurückzugeben... Was denkt ihr dazu??
Was ich persönlich bei Programmiersprachen vermisse, ist sozusagen ein Rechtesystem wie z.B. bei Betriebssystemen/Filesystemen d.h. jede Klasse hat bestimmte Rechte, die regeln wie und ob sie auf bestimmte Members von anderen Klassen zugreifen darf usw... Gibts sowas schon?? Soweit ich weiß, kann das weder C++ noch C#....
Naja, wichtiger ist mir die Frage mit der friend-Sache
-
todo schrieb:
Mal eine Frage, sind friend-Deklarationen/Anweisungen eigentlich ein Anzeiche für unsauberes Design? Im Prinzip verletzt man ja damit das Daten-Kapselungs-Konzept, auf der anderen Seite ist es manchmal nötig, weil man ja nicht hunderte von Routinen implementieren will, die nichts weiter machen, als ein member zu setzen bzw. zurückzugeben... Was denkt ihr dazu??
Nein, kein schlechtes Design (sofern richtig verwendet). Denn friends können die Kapselung erhöhen
stell einfach routinen bereit, mit denen sich die ganzen Algos implementieren lassen.
Was ich persönlich bei Programmiersprachen vermisse, ist sozusagen ein Rechtesystem wie z.B. bei Betriebssystemen/Filesystemen d.h. jede Klasse hat bestimmte Rechte, die regeln wie und ob sie auf bestimmte Members von anderen Klassen zugreifen darf usw... Gibts sowas schon??
Was sollte das bringen? Eine Klasse wäre keine unabhängige Einheit mehr, es wäre fest an eine Infrastruktur gebunden.
Und das Problem der Erweiterung hättest du auch: was machst du zB mit abgeleiteten Klassen.
Ich habe weder friends oft benutzt, noch mir ein anderes 'Rechtesystem' gewünscht. Vielleicht versteh ich den Sinn, wenn du ein gutes Beispiel bringst?
-
Hallo,
bisher habe ich friend nur im Zusammenhang mit Operator - Überladung gesehen.
Aber es gibt bestimmt noch mehr Anwendungsbeispiele.Meiner Meinung nach sollte man mit friend/static vorsichtig umgehen.
Es gibt eigentlich keinen Grund (außer in Ausnahmefällen) das Prinzip der Datenkapselung zu verletzen.Bin gespannt, wie die Anderen darüber denken
MfG
-
Ich glaube Eiffel hat eine feinere Rechteunterteilung zwischen Klassen.
Sinnvoll fuer C++ faende ich noch etwas staerkeres als private: Auch Instanzen gleicher Klassen sollten Klassenmember voneinander verstecken koennen.
-Gunnar
-
Gunnar_ schrieb:
Ich glaube Eiffel hat eine feinere Rechteunterteilung zwischen Klassen.
Jep, man kann zu jedem Block von Features (Eiffel-Jargon für Klassenmember) angeben, welche Klassen darauf zugreifen können. ANY steht dabei für public, default ist private auf Klassenebene, NONE ist sogar Instanz-privat.
Sinnvoll fuer C++ faende ich noch etwas staerkeres als private: Auch Instanzen gleicher Klassen sollten Klassenmember voneinander verstecken koennen.
private hat den Sinn, die Implementierung der Klasse zu schützen, d.h. zu verhindern, dass Dritte von Klasseninterna abhängig werden und es damit erschweren, die Implementation zu ändern. Per Definition ist eine Klasse von sich selbst abhängig, so dass ein solcher Zusatzschutz auf Instanzebene nichts bringt.
Der Bedarf daran deutet aber IMHO auf sehr große und unübersichtliche Klassen hin, an denen möglicherweise von mehreren Programmierern, die untereinander keine ausreichende Kommunikation unterhalten, gearbeitet wird.
-
es würde ja oft schon reichen, wenn man festlegen könnte, welche klassen lesend und welche schreibend auf ein (von mir aus öffentliches) member zugreifen dürfen... dadurch bräuchte man keine extra routinen für den zugriff implementieren und hat doch irgendwo die daten gekapselt/sicher...
EdiRitter schrieb:
Meiner Meinung nach sollte man mit friend/static vorsichtig umgehen.
warum mit static vorsichtig umgehen?? kann oft recht nützlich sein und spart auch unnötige instanzierungen der klasse...