Если проблема заключается в том, что внешние пользователи могут создавать свои собственные DataStore объекты, используйте их вне контекста DataProvider, и они жалуются, что ваша библиотека не работает, есть простое решение, а некоторые нет.Простые решения.
Простое решение: Документируйте, что DataProvider - это внешний интерфейс вашей библиотеки.Это решение используется в стандартной библиотеке C ++ и в Boost.Интерфейс для std::map является заголовочным файлом <map>.Файлы реализации, которые этот заголовок #includes, и базовые типы данных, создаваемые <map> и его вспомогательные заголовки, не относятся к вашему бизнесу.Вам следует использовать только общедоступные интерфейсы std::map.Используйте внутренние типы данных, и вы попадете в мир неопределенного поведения.Такие комментарии, как // The class DataStore is for internal use only. Use it and you will be fired., могут быть довольно мощным сдерживающим фактором.
Решение, которое не опирается на вышеприведенное: отгородите эти вспомогательные классы, определив их внутри DataProvider (например, вы получите класс DataProvider::DataStore) и сделать эти определения классов приватными / защищенными для DataProvider.Другой подход состоит в том, чтобы сделать все в DataStore приватным / защищенным и сделать DataProvider классом друга.
Поскольку вы предоставляете статическую библиотеку и заголовки, всегда найдутся некоторые неприятные хакерские средства, чтобы добраться доваши основные данные и методы, независимо от того, как сильно вы пытаетесь оградить их.В какой-то момент подход «» предназначен только для внутреннего использования. Держите грязные руки подальше! »имеет немало достоинств.