История изменений
Исправление hobbit, (текущая версия) :
добавилось еще два, отличающиеся только одной вложенной структурой (внутри базового) и вызывающие другой API (D2XX вместо виртуального COM порта, отличается грубо говоря префиксом в именах функций и использованием той самой структуры)
Ну окромя шаблонов, макросов и if-ов есть вариант ввести ещё один уровень наследования, вынеся в «промежуточный» класс максимум копипасты. Не факт, что это лучшее решение, вполне возможно, что с шаблонами будет изящнее и прозрачнее.
А ещё меня терзает смутное подозрение, что у первых двух классов (судя по комментариям к их объявлению) вероятно, должно было быть не наследование, а включение. Т.е. в потомке у тебя получается не разновидность предка, а класс, который «делает, что-то ещё», опираясь на методы предка.
Если моя догадка верна, то вполне возможно, что вместо CSerialEx и CFTSerialEx можно сделать один класс, а вот в качестве низкоуровневой прослойки ему можно передавать абстрактный класс работы с портом, у которого есть два потомка-реализации. Классов по-прежнему 4, но копипасты в них будет минимум
Собственно говоря, это очень похоже на диаграмму классов в вики-статье про паттерн «Стратегия» :) Да по сути, это она и есть... Хотя вру, для классической «стратегии» из статьи классов понадобится уже 5.
Хотя если CSerialEx и CFTSerialEx в низкоуровневой части не полностью полагаются на предков, а добавляют ещё какие-то вызовы API, это не спасёт.
Исправление hobbit, :
добавилось еще два, отличающиеся только одной вложенной структурой (внутри базового) и вызывающие другой API (D2XX вместо виртуального COM порта, отличается грубо говоря префиксом в именах функций и использованием той самой структуры)
Ну окромя шаблонов, макросов и if-ов есть вариант ввести ещё один уровень наследования, вынеся в «промежуточный» класс максимум копипасты. Не факт, что это лучшее решение, вполне возможно, что с шаблонами будет изящнее и прозрачнее.
А ещё меня терзает смутное подозрение, что у первых двух классов (судя по комментариям к их объявлению) вероятно, должно было быть не наследование, а включение. Т.е. в потомке у тебя получается не разновидность предка, а класс, который «делает, что-то ещё», опираясь на методы предка.
Если моя догадка верна, то вполне возможно, что вместо CSerialEx и CFTSerialEx можно сделать один класс, а вот в качестве низкоуровневой прослойки ему можно передавать абстрактный класс работы с портом, у которого есть два потомка-реализации. Классов по-прежнему 4, но копипасты в них будет минимум
Собственно говоря, это очень похоже на диаграмму классов в вики-статье про паттерн «Стратегия» :) Да по сути, это она и есть...
Хотя если CSerialEx и CFTSerialEx в низкоуровневой части не полностью полагаются на предков, а добавляют ещё какие-то вызовы API, это не спасёт.
Исходная версия hobbit, :
добавилось еще два, отличающиеся только одной вложенной структурой (внутри базового) и вызывающие другой API (D2XX вместо виртуального COM порта, отличается грубо говоря префиксом в именах функций и использованием той самой структуры)
Ну окромя шаблонов, макросов и if-ов есть вариант ввести ещё один уровень наследования, вынеся в «промежуточный» класс максимум копипасты. Не факт, что это лучшее решение, вполне возможно, что с шаблонами будет изящнее и прозрачнее.
А ещё меня терзает смутное подозрение, что у первых двух классов (судя по комментариям к их объявлению) вероятно, должно было быть не наследование, а включение. Т.е. в потомке у тебя получается не разновидность предка, а класс, который «делает, что-то ещё», опираясь на методы предка.
Если моя догадка верна, то вполне возможно, что вместо CSerialEx и CFTSerialEx можно сделать один класс, а вот в качестве низкоуровневой прослойки ему можно передавать абстрактный класс работы с портом, у которого есть два потомка-реализации. Классов по-прежнему 4, но копипасты в них будет минимум.
Хотя если CSerialEx и CFTSerialEx в низкоуровневой части не полностью полагаются на предков, а добавляют ещё какие-то вызовы API, это не спасёт.