Шаблон дизайна последовательной связи - PullRequest
3 голосов
/ 07 февраля 2011

В настоящее время мне поручено разработать программный модуль для связи с контроллером шагового двигателя.Проект написан на C #, у меня есть C ++ dll для связи с контроллером.Связь осуществляется через последовательный порт.Я планирую написать весь кусок в C #, импортируя необходимые методы с помощью DllImport.Метод key выглядит примерно так:

ComSendReceive(pHandle, bufferIn,sizeBufferIn,bufferOut,ref bufferOut)

Существует несколько типов сообщений:

  • Вы отправляете сообщение и ожидаете подтверждения (не то же самое для каждого сообщения, иногда все в порядке,иногда это ПОЛНАЯ и т. д.
  • Вы отправляете сообщение и получаете сообщение - вы можете получить ошибку или данные (например, GET_CONTROLLER_ID)
  • Несколько других типов

ИзКонечно, мне нужно контролировать общение в течение тайм-аутов.

Мой вопрос: есть ли какой-либо «шаблон проектирования», который можно использовать для решения такого рода проблем? Уверен, это довольно распространенная проблема, с которой сталкиваются многие разработчики.уже решен.

Чтобы внести небольшой вклад - я имел дело с подобной проблемой в своей последней работе и решил ее следующим образом:

У меня был класс для связи с портом Com и класс AT_messageс кучей перегруженных конструкторов:

class AT_Message
{
    public bool DoResponseCheck;
    public string ExpectedResponse;
    public AT_COMMAND command;
    public string data;
    public bool AddCarriageReturn;
    ...

    //Plenty of ctors
}

class UnfriendlyInterface
{
     Response SendMessage(AT_Message msg)
     {
         //Communicates directly with C++ dll, send message, check timeouts etc....
     }
}

И у меня был класс, с которым общалось основное приложение, у него были удобные для человека методы, такие как

class FriendlyInterface
{
     bool AutodetectPortAndOpenComm();

     Result AnalyzeSignal(byte[] buffer)
     {
         Response response = UnfriendlyInterface.SendMessage(new Message(AT_Command.PrepareForSignal, (doResponseCheck)true, ExpectedResponse.Ok,Timeout.short);
         Response response = UnfriendlyInterface.SendMessage(new Message(buffer,(doResponseCheck)false,Timeout.long);

         //.... Other steps
     }

     //... other methods

}

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

1 Ответ

0 голосов
/ 13 февраля 2011

Это похоже на шаблон фасада учебника. Ответом на все это является инкапсуляция вашего варианта. Например, попробуйте создать общий интерфейс для команд, которые дают подтверждение, и напишите клиентский код для использования этого интерфейса. Затем конкретные типы могут решить, как интерпретировать различные подтверждения в единый сигнал (Ok = Complete = Good или что-то еще)

Вот хорошая статья о схеме фасада . Также см. статью в Википедии .

...