Использовать наследование или кодировать разные варианты USART

Question

Использовать наследование или кодировать разные варианты USART

У меня есть класс USART, который передает данные с использованием прерывания TX.
Теперь я хочу создать вариант, который использует DMA для передачи данных.
Что бы вы предпочли:

использовать наследование для создания двух подклассов USART, например, ISRUSART, а DMAUSART?

или же

просто реализовать проверку варианта в коде. Позвольте пользователю указать в конструкторе, должен ли dma быть включен, а затем выполнить проверки в коде, чтобы решить, что делать (включить прерывание или загрузить dma)?

0

c++dma embedded usart

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Это не может быть тривиально ответить. Как и во многих дизайнерских решениях, это случай «дьявол кроется в деталях». Поэтому мой ответ здесь будет не «пойти с решением A» или «пойти с решением B», а скорее «Что вам нужно посмотреть, чтобы решить, какой путь идти» — так как это также поможет вам больше, чем просто даю прямое «Вы должны выбрать ответ А», так как он проведет вас через весь процесс, и вы сможете использовать этот процесс и для будущих проектных решений.

Основными вопросами являются:

Насколько отличается код?
Как это будет использоваться?
Каковы преимущества одного решения над другим?
Каковы недостатки одного решения над другим?

Вы единственный, кто может ответить на подобные вопросы, потому что у нас нет вашего кода, и мы не знаем аппаратное обеспечение, над которым вы работаете.

Чтобы уточнить пункты выше:

Если разница в кодах между «с DMA» и «без DMA» очень минимальна и может быть добавлена с помощью пары «если» в нужных местах, то это, вероятно, правильное решение. С другой стороны, если есть много разных мест, то это хороший аргумент для разделения кода, чтобы сделать его более понятным.

Как используется код, также является критическим вопросом для дизайна. Вам необходимо определить, где и как делается выбор прямого доступа к памяти и прерывания, и где он находится. Это фабричная функция, которая затем инициализирует правильный производный класс из class BaseSerial, Там также может

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

В общем, наличие общего интерфейса / базового класса, а затем и производного класса кажется разумным решением. Но если это сделано неправильно, то это может быть по меньшей мере таким же запутанным и сложным, как использование «более простого» подхода и иметь два набора кода.

Естественно, нужно также учитывать производительность. Если вы добавите дополнительные слои (которые на самом деле генерируются в коде, а не оптимизируются), то это может повлиять на общую производительность устройства, как и «ненужные операторы if / else». Опять же, не понимая деталей реального дизайна, трудно сказать, какое решение лучше с точки зрения производительности.

Возможно, это хорошая идея, чтобы поэкспериментировать и создать прототип с тем, что, по вашему мнению, является правильным решением, посмотреть, как это «выглядит» и «чувствует», и, если оно может быть правильным, то пойти на это. Если он «чувствует себя не так», вернитесь и посмотрите на другое решение. Повторяйте до тех пор, пока вы либо не найдете хорошее решение, либо не будете вынуждены выбирать наименее плохое, потому что у вас заканчивается время ….

2