Разрабатывая приложение, работающие с драйвером пришел к выводу, что это будет не последним приложением подобного рода. Таким образом возникла мысль о написании библиотеки двух классов: CDriver  и CDevice. Цель первого это позволить приложению установить\удалить , запустить\остановить драйвер. А назначение второго это открыть\закрыть устройство и послать ему IO-команду посредством функции Win32 API - DeviceIOCode.
Если со вторым, CDevice, мне более-менее понятно и уже чуть-ли не на 80% его разработал, то первый CDriver меня утопил. Под "утопил" это вечный цикл разработки. Мне каждый день кажется, что надо переписать, глядя на вчера придуманный интерфейс.

В чем смысл темы?

В просьбе подсказать методы позволяющие проектировать, чтобы не на теории, как это в Гради Буч, а на практике. Услышал вчера от BSA по аське: "смотри Qt и учись писать как там". Однако к этому еще придти надо! ;) Также еще от одного знакомого услышал метод разработки через разработку тестирования интерфейсов, не путать с юнит-тестированием. Тестирование интерфейсов, по его словам, заключается в том что ты пишешь код будущего, еще не существующего класса, при этом сразу становится понятным что тебе еще не хватает или не удобно. Но пока это только в теории, на практике не понятно как к этому подойти!

Прошу подсказать метод позволяющий продумывать интерфейсы на примере CDriver.
Что хочу и что может?

Ситуация №1:
Приложение должно постоянно работать с драйвером, в ее ini-файле прописан путь к драйверу и имя устройства. Могут быть следующие случаи:
1) Драйвер уже установлен, через CreateService, но не запущен. Надо OpenServiceA -> StartService.
2) Драйвер может быть не запущен и не установлен. Надо установить OpenSCManagerA -> CreateServiceA -> StartService

При вызове Win32 API может потребоваться:
1) Путь к файлу
2) Сервисное имя
3) Дисплейное имя

Нюансы:
При запуске приложения, в ini-файле может быть не указано ни дисплейного ни сервисного имен, поэтому их нужно получить на  основании имени файла к драйверу без расширения. Пример: "c:\progra~1\app\super.sys" , сервисное "super", а дисплейное "super driver".
При запуске приложения, также может быть не указано имя устройства,  оно  может быть получено аналогично сервисным именам, но с добавлением префиксной строки "\\\\.\\" и переводом первой буквы в имени в верхний регистр. Пример "c:\progra~1\app\super.sys", имя устройства "\\\\.\\Super".

Хочется, посмотреть ход размышления опытных при разработке интерфейса класса ;)

При разработке интерфейсов (и не только) очень полезен метод use case'ов. Придумывается как можно больше реальных (возможных) конкретных случаев использования класса. Прикидывается, что и как у класса должно быть в интерфейсе, что бы реализовать каждый конкретный случай. Далее пытаешься минимизировать количество сущностей в интерфейсе, но так, что бы каждый конкретный случай все еще можно было бы реализовать (и желательно эффективно).
То, что получится в результате, и будет интерфейсом в первом приближении.

Тут главное ориентироваться именно на конкретные варианты использования, а не на абстрактный интерфейс в целом

Да, что-то получается. Но необходимо время для практики, что и будем делать ;) Это основной метод или есть еще ?

Вообще то их много еще есть   Это всего лишь одна из методик проектирования, причем не эксклюзивная, т.е. ее вполне можно сочетать с другими