Vererbung und Freunde: Sicherheitsmechanismus?

Question

Ich bin auf eine interessante Theorie gestoßen und habe mich gefragt, ob es in C++ einen Sicherheitsmechanismus dagegen gibt.

All dies ist legal - Klasse C ist ein Freund der Basis und kann daher b.a() anrufen. Da es jedoch eine Referenz erhalten hat, kann es eine Referenz auf ein abgeleitetes Objekt erhalten, und somit würde C auf den privaten Bereich in der Klasse Abgeleitet zugreifen, ohne ein Freund von abgeleitet zu sein.

Ist das einfach ein schlechtes Code-Design oder gibt es einen sicheren Schutz davor? Passiert mir, wenn ich den Operator < < für die Basis außer Kraft setze und eine allgemeine Druckfunktion von innen aufruft (der Operator war ein Freund der Basis).

Answer 1

Wie das Skelett des Designs (von Base und Derived) steht, ist dies ein typisches gutes Design, das von Herb Sutter 15 years ago befürwortet wurde - außer dass Freund Klasse C überflüssig ist, da es die öffentliche Funktion run aufrufen kann ().C muss nur dann ein Freund sein, wenn es nur a() benötigt, falls run() mehr Funktionalität vermeidet (und ich würde in einem solchen Fall ein schlechtes Design vermuten). Ich fragte mich, was falsch mit meinem Lesen war, denn im Gegensatz zu den vorherigen Antworten sehe ich nicht, dass a() öffentlich ist, noch sehe ich, dass Base eine private Basis ist. Genießen Sie

Answer 2

Hier sind keine Sicherheitsmaßnahmen erforderlich. So funktioniert C++.

Durch Überschreiben einer virtuellen Funktion in der Basisklasse wird die abgeleitete Klasse neu implementiert. Die Definition der "Neuimplementierung" beinhaltet jedoch, dass das gesamte Gepäck aus der Basisklasse übernommen wird. Einschließlich der Tatsache, dass die virtuelle Funktion in der Basisklasse in diesem Fall public ist.

Die Tatsache, dass die abgeleitete Klasse die neu implementierte Funktion als private definiert, ändert nichts an der Tatsache, dass sie eine öffentliche Funktion überschreibt. Und als solches sollte es erwarten, dass es weiterhin über die Basisklasse erreichbar ist.

höchstens, ich nehme an, Sie können dies eine "Eigenart" nennen. Die Quintessenz ist, dass, wenn Sie eine virtuelle Funktion public überschreiben, der Prozess des Überschreibens die Tatsache nicht ändert, dass es eine öffentliche Funktion ist. Die übergeordnete Funktion "privat", in der abgeleiteten Klasse, schließt die Scheune, nachdem die Pferde bereits gegangen sind.

Und Sie müssen sich der Tatsache bewusst sein, dass Sie eine öffentliche virtuelle Funktion überschreiben. In einigen Situationen würde ich sagen, dass dies sogar ein Feature sein kann. Es wäre nicht allzu schwierig, sich eine Situation vorzustellen, in der eine bestimmte Basisklassenfunktion nur von dem vorhandenen Code aufgerufen werden sollte, der direkt auf die Basisklasse verweist. Jeder Code, der über einen Zeiger oder eine Referenz auf die abgeleitete Klasse verfügt, ist Code höherer Ebene, auf dem kein Unternehmen die Funktionen der Basisklasse aufrufen darf. Dies wäre natürlich eine Möglichkeit, dies zu tun. Dies ist sicherlich nicht als eine Art eiserne Sicherheit gedacht, sondern lediglich ein Mechanismus für den Compiler, der Ihnen hilft, logische oder funktionale Fehler zu finden oder Fehler zu konstruieren.

Answer 3

Nun, nein, das ist nicht schlechtes Design von C++. Es ist ein schlechtes Design deines Programms.

Ein Programm, das etwas tut, wie

some_C.doSomething(some_derived); 

wird nicht kompilieren. Dies liegt daran, dass Ihre Base eine private Basis von Derived ist. Daher ist die Umwandlung von Derived & in Base & ungültig.

Die Ausnahme zu den oben genannten ist, wenn die aufrufende Funktion, die dies tut, entweder ein Mitglied oder friend von Derived ist. In diesem Fall wird das Verhalten vom (Entwickler von) Derived kontrolliert, wenn Sie so etwas getan haben, liegt es allein in Ihrer Verantwortung.