Автору посоветовал бы использовать паттерн декоратор (decorator) и назвать его к примеру Timer для класса или timer (timeit, ...) для функции(если в Вашем языке функция это first class citizen) как предлагал Валерий Глуховцев.
Обоснование:
Причина по которой Вы хотели бы использовать подобный класс это профилирование. И мне лично, не хотелось бы отделять объект измерения от самого измерения. Введение декоратора для измерения позволит обеспечить хорошую сцепленность. Самостоятельные классы следует создавать для необходимых сущностей, а не плодить их, так пропагандируют современные эксперты. И это еще опуская тот факт, что настоящий ООП сейчас в опале. Помимо декоратора, в зависимости от языка, я могу придумать так же использование метаклассов, но декоратор удобнее.
Почему я считаю, что измерение времени не достойно полноценного существования как отдельного класса?
- Класс предполагает порождение экземпляров. Которые в свою очередь будут вызываться в методах, когда мы хотим что то измерить? Это уже сильная связанность, которую следует избегать. А так же, в какой то мере увеличит code complexity score
- Вы написали:
В коде есть объект, единственное свойство которого это длительность его существования
Сами слова говорят, что цель такого объекта слишком мало для отдельной сущности. Это, наверное, "Одержимость элементарными типами" в концепции Код с запашком