"Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования"
К данному определению из ru.wikipedia.org есть вопросы. Например, почему для вывода определения используется такой термин как "класс", ведь сам по себе класс - это представление объекта, которое используется для реализации парадигмы, своеобразная рекурсия получается. На эту тему долго можно рассуждать, на мой взгляд более корректное определение дается на
en.wikipedia.org.
Ну и самый интересный вопрос, зачем эти классы нужны? Вам не кажется. что они как раз очень напоминают HAL с ее тяжеловесными функциями и огромным оверхедом?
Вы себе ставите задачу переписать HAL в виде классов?
Так как вопрос адресован не мне, я позволю себе его немного перефразировать, и попытаться ответить.
Стоит ли переписывать HAL (в данном случае от ST), в виде классов, или это бесполезная трата времени?
ответ: на мой взгляд, если основной инструмент разработки ПО - С++, то да, стоит. Чтобы использовать возможности языка без оглядки на совместимость с С при каждом вызове функции или метода. С и С++ - это разные языки, и для компиляции используются разные компиляторы. Да, во многих случаях код написанный на С соберется и на С++, и даже будет работать, но есть тонкие места, где поведение С компилятора и С++ будут различны. Например, не самое тонкое, но для программиста не привыкшего к С++ может быть поначалу не очевидным, например: union от структур, если в С все прозрачно и очевидно, то для С++ может возникать много вопросов, так как семантически struct в С++ это класс.
В продолжении ответа, для реализации классов вовсе нет необходимости отказываться от HAL, который предлагает ST, можно все это обернуть в свои классы. Такой очевидный, на первый взгляд, overhead может показаться абсолютно бессмысленным, но, если такая обертка будет хорошо спроектирована, то сам overhead будет не значительным, или его не будет вовсе, а вопрос о замене аппаратной части устройства будет значительно проще решаться. Причем замене не просто с STM32F1xx на STM32F4xx (эту задачу HAL ST и должен решать) например, а на любой другой МК, например от TI или Microchip. Потому что такая обертка позволит абстрагировать логику прибора от аппаратной части и реализаций предоставляемых вендором. Справедливости ради, стоит сказать, что абстракции можно и на С реализовать, в том числе с применением, горячо обсуждаемого, ООП.