Организация кросс-платформенного кода

Question

У меня есть этот класс монитора, который дает доступ к своим экземплярам со статической функцией.Когда вызывается GetMonitor, выполняется поиск карты mMonitors и возвращается экземпляр, если экземпляр не существует, он создается.

class Monitor {
    public:
        static Monitor& GetPrimaryMonitor();
        static Monitor& GetMonitor(int number = 0);
        int GetXResolution();
        int GetYResolution();
        void SetXResolution(int resolution);
        void SetYResolution(int resolution);

    protected:
    private:
        Monitor(int number);
        static std::map<int, Monitor*> mMonitors;
};

Мой вопрос заключается в том, когда следует удалять удерживаемые экземпляры Monitorна карте?Или я должен использовать другой подход, позволяющий пользователю создавать столько экземпляров монитора, сколько он / она хочет?Это кажется неправильным, потому что это было бы так, как если бы они создавали физический монитор, тогда как мой подход предоставляет доступ к уже доступным общим ресурсам.Заранее спасибо, эл.

Answer 1

Я бы посоветовал держаться подальше от синглетонов, особенно если они реализованы со статикой.Последствия этого паттерна поначалу не очевидны, но могут усложнить ситуацию позже (например, если у вас есть несколько двоичных файлов, DLL, заботитесь о конкретном порядке уничтожения и т. Д.).

Вы должны попытаться проверить,Вы можете изменить дизайн так, чтобы этот экземпляр Monitor мог передаваться по коду (своего рода внедрение зависимостей) вместо того, чтобы делать это как одиночный код (на самом деле это самый злоупотребляемый шаблон в ОО).

Answer 2

Должен ли я использовать другой подход, позволяющий пользователю создавать столько экземпляров монитора, сколько он / она хочет? Это кажется неправильным, потому что это было бы так, как если бы они создавали физический монитор, в то время как мой подход дает доступ к общим ресурсам, уже доступным

Да, вы должны. По нескольким причинам:

• Вы предоставляете пользователю абстракцию монитора, а не реального физического монитора. Поэтому не обязательно неправильно иметь другое количество объектов Monitor, чем у вас есть реальные физические мониторы.
• У разных пользователей может быть разное количество мониторов
• У людей могут быть «виртуальные» мониторы или, возможно, фиктивные реализации для тестирования, которые вообще никогда не соответствуют физическим мониторам.
• синглтоны просто ужасная идея .

Answer 3

В любом случае, будьте последовательны и очевидны в отношении того, что они должны делать.

Меняется ли количество мониторов?

Если нет, я бы сказал, что вам лучше оставить одну версию и сохранить право собственности. Не позволяйте или заставляйте пользователей уничтожать их.

Если это так, вернуть общий / автоматический указатель или что-то копируемое. Я подозреваю, что последний вариант является правильным, если только создание и уничтожение ваших ссылок на внутреннее устройство не обходится слишком дорого. Это умозрительно, хотя.

Функции инициализации / очистки в вашем главном не красивы и не изящны, но они эффективны и очень прямо сообщают о ваших намерениях.

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

size_t GetNumMonitors();
void GetMonitorSize(size_t idx, int &x, int &y);
void SetMonitorSize(size_t idx, int x, int y);

Если вам действительно нужен дизайн объекта, скройте его за этим (или похожим) интерфейсом. Это освобождает пользователя от работы с вашей реализацией.

Answer 4

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

Что касается создания экземпляров, вы можете придерживаться того же подхода.Вы можете создать новый объект, когда пользователь запрашивает его (1) или когда подключено новое устройство мониторинга (2).Если есть возможность подключить устройство мониторинга к системе, но ничего не делать с ним в контексте вашего приложения, я бы использовал (1).С другой стороны, если каждый раз, когда новое устройство монитора подключается к системе, например, ваше приложение должно получить разрешение устройства, я бы использовал (2).