Логический и физический дизайн

Question

У меня очень общий вопрос о дизайне, но я сформулирую его в конкретных терминах на примере.

Предположим, вы работаете над встроенным программным обеспечением для цифрового принтера. Машина имеет 4 печатающих головки (для каждого из цветов C, M, Y, K). Каждая печатающая головка выполняет одну и ту же задачу: извлекает тонер и помещает его на страницу.

Во время выполнения мы могли бы организовать наш API двумя различными способами. Либо мы придерживаемся логического («функционального» или «технологического») дизайна, чтобы клиентское программное обеспечение могло контролировать процесс печати на всех печатающих головках (например, изменять яркость всех цветов одновременно). Или мы придерживаемся физического плана, чтобы клиентское программное обеспечение могло управлять каждой печатающей головкой индивидуально (например, изменять яркость только пурпурного цвета).

Это классическая дилемма в разработке программного обеспечения: мы организуем либо по видам деятельности, либо по архитектуре. По функции или по форме. У меня вопрос: есть ли какие-то твердые критерии для выбора одного над другим? Различные проекты будут выбирать по-разному и оба могут быть правильными в зависимости от их собственной ситуации; так что я не спрашиваю, что лучше, только как выбрать. Например. Мне были бы интересны ваши идеи по поводу слабой связи, ремонтопригодности, наслоения, ролевого проектирования, архитектурных шаблонов проектирования и т. Д.

Answer 1

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

Answer 2

Сделайте самое простое, что соответствует требованиям проекта.

Кодирование как логического, так и физического проектов может привести к ненужным усилиям по разработке (и, следовательно, к стоимости), если логический проект соответствует требованиям проекта.

Answer 3

Полагаю, это зависит от того, чего хотят ваши клиенты - от требований системы с точки зрения клиентов.

Лично я бы предпочел разложить проблему на две меньшие части / вопросы:

Код низкого уровня для доступа и контроля физических компонентов - физического API. (Это всегда нужно делать в любом сценарии проектирования, который вы выберете, чтобы на нем можно было сфокусироваться и сделать).

Использование API выше обеспечивает более структурированный API для функций / процессов (при необходимости)

НТН Len