@Kir, проще, наверное, почитать. ООП - это не только, и даже не столько полиморфизм, не стоит сводить всё к нему.
Не только, но вся сила и мощь, если угодно, ООП раскрывается именно в полиморфизме. А чисто технически в С++, для реализации полиморфизма, необходимо использовать и инкапсуляцию, и наследование.
@Kir, Реализация в С++ предполагает, что типы данных будут известны на этапе компиляции и, соответственно, "гвоздями прибиты" как в реализации (нужно для каждого типа и вида написать свой обработчик), так и в использовании (результат может быть присвоен переменной только определенного типа).
Да, потому, что язык статически типизированный, как и C#, и Java.
@Kir, Элементы полиморфизма присутствуют даже в той библиотеке, что использует ТС: возможна обработка как "цифровых клавиатур", так и "аналоговых" одинаковыми методами. Только ТС даже в таком виде не стал с этим разбираться, а просто решил, что библиотека плохая, раз ещё и самому к ней код нужно писать. Типичный подход, скажем прямо.
Что это за элементы полиморфизма, он либо есть, либо его нет, а его там нет. ТС тут вообще ни при чем, дискуссия об ООП и полиморфизме началась иначе.
@Kir, И, скажите начистоту, зачем для обработки одной команды чтения регистра Вам нужен полиморфизм? Да и ООП?
Вот об этом я и говорю, что нет понимания сути. Зачем оно вообще нужно, если можно и без него все сделать?
Суть приемов ООП в том, чтобы проще было управлять осями изменений. Ось изменений это место, где может проходит какое-то изменение, как ни странно)))
Пример, немного утрированный, но вполне возможный в реальности: у вас проект, в котором используется gpio для вывода какой-то информации. Сделали, все работает, замечательно. Но потом выясняется, что нужно добавить функционал, но для этого необходимо освободить пины (ШИМ например понадобился, или интерфейс какой, не суть важно), которые уже заняты, а в качестве компенсации использовать расширитель портов, решили, что это будут сдвиговые регистры. Скорее всего вам придется придется переписать уже отлаженную программу, что может её сломать, и потом снова придется отлаживать. а потом может оказаться, что придется поменять сдвиговый регистр на расширитель портов по i2c, так как SPI нужен в другом месте, что вас ждет - переписывание программы в 3-й раз.
Что нам могут дать приемы ООП, создать абстракцию (интерфейс) для gpio, и несколько реализаций: обычный порт, сдвиговый регистр, расширитель портов по i2c. Основная логика программы не знает о реализации, так как работает с абстрактным интерфейсом, и когда придется поменять работу с портом, не нужно переписывать уже отлаженную основную программу, достаточно просто сделать нужную реализацию, если её ещё нет. Так же это хорошо сработает, если вам необходимо переехать на другой МК, достаточно переделать реализации интерфейсов, а код основной программы не изменяется, кроме всего прочего улучшится читаемость основной программы, за счет удаления из неё деталей реализации gpio,
Другой пример, который касается конкретно полиморфизма. Часто наверное приходилось сталкиваться с лестницами из операторов ветвления, опять же, нужно добавить что-то, это ещё один
else if
. Если их много, и код в составных операторах объемный и не простой, наверное тут лучше использовать полиморфизм, читаться будет в разы лучше, а если придется что-то добавить или поправить, то не придется лезть в основную программу. Почему так происходит, потому что происходит инверсия зависимости, так как основная программа перестает зависеть от конкретной реализации, а конкретная реализация зависит от интерфейса, который использует основная программа.
@Kir, Упоминаемая библиотека создана для тех, кому простейшая логика кажется неподьемной. Выясняется, что даже это свойство "сокрытия логики" не помогает, когда отсутствует логика работы кода, написанного извне. Поэтому аргумент, что здесь бы помог полиморфизм (ООП, интерфейсы, ...) - это в пользу раздувания кода из ничего. И именно поэтому часто код на С значительно более управляемый в таких применениях, чем ООП, не говоря о том, что существенно более быстрый и короткий.
Никто не говорит, что полиморфизм тут прямо необходим, и без него тут делать нечего, был задан вопрос, а возможно ли так, да возможно, а почему никто так не делает, далее я привел свои доводы почему.
Никто никого не заставляет все делать с использованием ООП. ООП это концепция, её либо используют, либо не используют. Если используют получает один код, если не используют, получается другой код. Использование/не использование не означает хорошо/плохо. Плохим или хорошим может быть проектирование и реализация, и не важно какая выбрана концепция.