Дружба не унаследована - каковы альтернативы?

Я написал / пишу фрагмент кода для анализа физики, первоначально для себя, который теперь, надеюсь, будет использоваться и расширяться небольшой группой физиков. Никто из нас не гуру C ++. Я собрал небольшую структуру, которая абстрагирует данные "физических событий" в объекты, на которые действует цепочка инструментов, которые можно легко менять местами в зависимости от требований анализа.

Это привело к созданию двух половин кода: код «физического анализа», который манипулирует объектами событий и выдает наши результаты через производные от базового «Инструмента»; и «структурный» код, который присоединяет входные файлы, разделяет задание на параллельные прогоны, связывает инструменты в цепочку в соответствии с одним скриптом и т. д.

Проблема заключается в следующем: для того, чтобы другие использовали код, важно, чтобы каждый пользователь должен иметь возможность следить за каждым шагом, который каким-либо образом изменяет данные события. Поэтому (многие) лишние строки сложного структурного кода могут быть пугающими, если только они не являются очевидными и очевидными второстепенными для физики. Хуже того, слишком подробный взгляд на это может дать людям идеи - и я бы предпочел, чтобы они не редактировали структурный код без веской причины - и, что наиболее важно, они не должны вводить ничего, что влияет на физику.

Я бы хотел хотел бы иметь возможность:

• А) продемонстрировать очевидным образом, что структурный код не редактирует данные о событиях любым способом
• B) принудительно применять это, когда другие пользователи сами начните расширять код (никто из нас не эксперт, а физика всегда приходит сначала - перевод: ничего нет скрученный - справедливая игра для противного hack)

В моем идеальном сценарии данные событий были бы частными, а производные инструменты физики наследуют доступ от базового класса Tool. Конечно, на самом деле это недопустимо. Я слышал, что для этого есть веские причины, но проблема не в этом.

К сожалению, в этом случае метод вызова геттеров / сеттеров из базы (которая является другом) создаст больше проблем, чем решает - код должен быть максимально понятным, простым в использовании и максимально связанным с физикой при реализации самого инструмента (пользователю не нужно быть экспертом ни в C ++, ни во внутренней работе программы для создания инструмента).

Учитывая, что у меня есть доверенный базовый класс и любые производные инструменты будут подвергаться тщательной проверке, есть ли какой-либо другой обходной, но хорошо проверенный способ разрешить доступ только к этим производным? Или каким-либо способом запретить доступ к производным какой-либо другой базы?

Чтобы прояснить ситуацию, у меня есть что-то вроде

class Event
{
    // The event data (particle collections etc)
};

class Tool
{
    public:
        virtual bool apply(Event* ev) = 0;
};

class ExampleTool : public Tool
{
    public:
        bool apply(Event* ev)
        {
            // do something like loop over the electron collection
            // and throw away those will low energy
        }
};

Идеальным было бы ограничить доступ к содержимому Event только этими инструментами по двум причинам (A и B) выше.

Спасибо всем за предложенные решения. Я думаю, как я и подозревал, идеальное решение, которого я искал, невозможно. Решение dribeas было бы идеальным в любой другой настройке, но именно в функции apply () код должен быть как можно более ясным и лаконичным, поскольку мы в основном потратим весь день на написание / редактирование функций apply (), а также нужно понимать каждую строчку из них, написанную каждым из других. Дело не столько в возможностях, сколько в удобочитаемости и усилиях. Мне очень нравится препроцессорное решение от "Бесполезного". На самом деле это не приводит к разделению, но кто-то должен быть действительно злым, чтобы его нарушить. Для тех, кто предложил библиотеку, я думаю, что это определенно будет хорошим первым шагом, но на самом деле он не решает двух основных проблем (так как мне все равно нужно предоставить исходный код).