LINUX.ORG.RU

Статические методы или синглтоны менеджеры?


0

1

Очень сталкиваюсь с проблемой менеджмента объектов. Например, сейчас пишу класс Profiler для замера скорости выполнения участков кода. Объектами этого класса нужно управлять, так как например одна функция может выполнятся несколько раз и в профайле нужно подсчитывать количество вызовов, среднее время исполнения и т.д.
Есть два варианта менеджмента этих объектов:
1. Создать статические методы в Profiler:

/// Делает профайлер текущим, осуществляется замер времени  
static void startProfiler(int id);   
/// Замер времени останавливается    
static void stopProfiler(int id);
Минус этого подхода в том, что класс Profiler теперь имеет две обязанности, имеет много статических методов и членов не особо относящихся к основной задаче класса.

2. Создать менеджер-синглтон который и будет осуществлять менеджмент объектов класса. Минус этого подхода в том, что нужно осуществлять менджмент большого количества экземлпяров разных классов и на каждый такой класс делать собственный менеджер. То есть, например у меня есть различные ресурсы: текстуры (1D, 2D, 3D, Cube), меши, изображения, шейдеры, шрифты, материалы и т.д.. Иногда требуются методы для загрузки всех ресурсов, обращению к некоторому ресурсу и т.д. Не слишком ли много менеджеров будет?

Вот теперь думаю как лучше делать. Со статическими методами выглядит весьма просто - но не знаю как он поведет себя в долгосрочной перспективе. Использование менеджеров смотрится как ООП-way, но на каждый ресурс по своему менджеру - очень много классов.

если правильно понял, то можно же не членами класса делать статические методы, а глобальные, например с разными id, ну и фильтрами внутри методов, с разной логикой. И синглтон то не нужен(хотя смотря куда пишешь статистику). Для более удобного отслеживания можешь сделать класс по типу mutex_locker, имею ввиду в конструкторе будет начинать отсчет, в деструкторе завершать, можно объявить как член класса - тогда будет писать время жизни объекта, либо в функции в самом начале(ну чтоб в конце не вызывать завершение), к примеру.

Blastbit ()

но на каждый ресурс по своему менджеру - очень много классов.

а чем не устраивает один менеджер - фабрика для всех типов ресурсов?

x0r ★★★★★ ()

Минус этого подхода в том, что класс Profiler теперь имеет две обязанности, имеет много статических методов и членов не особо относящихся к основной задаче класса.

Бла-бла-бла.

То есть, например у меня есть различные ресурсы: текстуры (1D, 2D, 3D, Cube), меши, изображения, шейдеры, шрифты, материалы и т.д.. Иногда требуются методы для загрузки всех ресурсов, обращению к некоторому ресурсу и т.д. Не слишком ли много менеджеров будет?

Не слишком, потому что программист всё равно воспринимает API как плоский список функций, независимо от того, куда именно они упакованы.

quiet_readonly ★★★★ ()
Ответ на: комментарий от quiet_readonly

программист всё равно воспринимает API как плоский список функций

ШТА? Об ООП ничего не слышал?

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)

1) синглтоны - плохо, dependency injection лучше
2) нужно сделать как-то так, чтобы менеджеры не начали измерять самих себя. Судя по «одна функция может выполнятся несколько раз» время работы профайлера будет частью времени работы функции?
3) я за базовый класс для всех менеджеров, в котором простые случаи типа startById/stopById будут из коробки. Стараться всегда оставаться в пределах базового класса, н-р с помощью convention over configuration. Ну и reflection, но тут уже см. п.2, профайлер не должен начать замерять самого себя.

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

ШТА? Об ООП ничего не слышал?

ООП-мышление работает на отдельных объетах, а в случае глобального АПИ хоть там синглтон, хоть статические методы, хоть свободные функции — программист воспринимает это одним списоком функций.

quiet_readonly ★★★★ ()
Ответ на: комментарий от stevejobs

do_smth(obj, arg) => obj.do_smth(arg) - ахренеть как это все меняет с точки зрения восприятия.

dizza ★★★★★ ()

Я за статические методы. Всякую утилитарную хрень обычно удобно как статик методы дергать. Если смущает единственность обязанностей, то сделай так: класс Profile содержит static-методы, а стейт вынеси в отдельный класс ProfileContext.

dizza ★★★★★ ()
Ответ на: комментарий от dizza

Вообще-то да, меняет! Достаточно вспомнить разницу между CLOS и остальными объектными системами.

yoghurt ★★★★★ ()
Ответ на: комментарий от dizza

ты тоже об ООП не слышал :3 вместо obj.do_smth, можно сделать MyObject extends Framework implements DoSomething, либо разметить аннотациями @somethingable (которые автоматически будут дергать что нужно на разных этапах), либо использовать reflection для того, чтобы сконструировать do_smth на основе конвенции наименований (do_smth = do_before+do_content+do_after), итп.

stevejobs ★★★★☆ ()

Всё цивилизованное человечество давно придумало интерфейс синглтона, состоящий из одного метода. Ты придумал синглтон с двумя методами, которые выворачивают наружу кишки. Поздравляю.

По поводу большого количества «менеджеров»: шаблон проектирования называется Service Locator.

/thread

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.