Freundschaft nicht geerbt - was sind die Alternativen?

Ich habe geschrieben / schreibe ein Stück Physik-Analyse-Code, zunächst für mich selbst, das hoffentlich jetzt von einer kleinen Gruppe von Physikern benutzt und erweitert wird. Keiner von uns ist C ++ Gurus. Ich habe ein kleines Framework zusammengestellt, das die "Physikereignis" -Daten in Objekte abstrahiert, die von einer Kette von Werkzeugen beeinflusst werden, die je nach den Analyseanforderungen leicht ein- und ausgegliedert werden können.

Dies hat zwei Hälften des Codes erzeugt: den "Physikanalyse" -Code, der die Ereignisobjekte manipuliert und unsere Ergebnisse über Ableitungen eines Basis "Tools" erzeugt; und der "strukturelle" Code, der Eingabedateien anfügt, den Job in parallele Läufe aufteilt, Werkzeuge in eine Kette gemäß einem Skript usw. verbindet.

Das Problem ist folgendes: Damit andere den Code nutzen können, ist es wichtig, dass jeder Benutzer in der Lage ist, jedem einzelnen Schritt zu folgen, der die Ereignisdaten in irgendeiner Weise verändert. Die (vielen) zusätzlichen Linien von schwierigem strukturellem Code könnten daher entmutigend sein, es sei denn, sie sind offensichtlich und nachweisbar peripher zur Physik. Schlimmer noch, wenn man es zu sehr ins Detail betrachtet, könnte man den Leuten Ideen geben - und ich würde es lieber, wenn sie den Strukturcode nicht ohne guten Grund bearbeiten würden - und vor allem dürfen sie nichts einführen, was die Physik beeinflusst.

Ich würde gerne in der Lage sein:

• A) demonstrieren das auf anschauliche Weise Der Strukturcode bearbeitet nicht die Ereignisdaten in irgendeiner Weise
• B) erzwingen dies einmal andere Benutzer Beginne, den Code selbst zu erweitern (keiner von uns ist Experte, und die Physik kommt immer erste - Übersetzung: alles nicht verbolzt ist faires Spiel für eine böse hack)

In meinem idealen Szenario würden die Ereignisdaten privat sein, wobei die abgeleiteten Physikwerkzeuge den Zugriff von der Tool-Basisklasse erben würden. In der Realität ist das natürlich nicht erlaubt. Ich höre, es gibt gute Gründe dafür, aber das ist nicht das Problem.

Leider würde in diesem Fall die Methode, Getter / Setter von der Basis (die ein Freund ist) aufzurufen, mehr Probleme verursachen als es löst - der Code sollte so sauber, einfach zu folgen und mit der Physik verbunden sein wie es bei der Implementierung des Tools selbst möglich ist (ein Benutzer sollte weder Experte in C ++ noch die inneren Abläufe des Programms sein müssen, um ein Tool zu erstellen).

Da ich eine vertrauenswürdige Basisklasse habe und alle Derivate genau unter die Lupe genommen werden, gibt es noch einen anderen, aber gut getesteten Weg, um nur diese Derivate zuzulassen? Oder irgendeine Möglichkeit, den Zugang zu den Derivaten einer anderen Basis zu verweigern?

Um die Situation zu klären, habe ich etwas wie

Das Ideal wäre, den Zugriff auf den Inhalt von Event auf nur diese Tools aus den beiden oben genannten Gründen (A und B) zu beschränken.

Vielen Dank für die vorgeschlagenen Lösungen. Ich denke, wie ich vermutete, ist die perfekte Lösung, die ich mir wünschte, unmöglich. Die Lösung von dribeas wäre in jeder anderen Umgebung perfekt, aber genau in der apply () -Funktion muss der Code so klar und prägnant wie möglich sein, da wir im Grunde den ganzen Tag mit dem Schreiben / Bearbeiten von apply () - Funktionen verbringen werden Ich muss jede Zeile verstehen, die von jedem der anderen geschrieben wurde. Es geht nicht so sehr um Fähigkeiten wie Lesbarkeit und Anstrengung. Ich mag die Präprozessorlösung von "Useless". Es erzwingt nicht wirklich die Trennung, aber jemand müsste wirklich böswillig sein, um es zu brechen. Für diejenigen, die eine Bibliothek vorgeschlagen haben, denke ich, dass dies definitiv ein guter erster Schritt sein wird, aber nicht wirklich die beiden Hauptprobleme angeht (da ich die Quelle immer noch bereitstellen muss).