Рекомендации по разработке стратегии для определения функциональности системы машины - PullRequest
3 голосов
/ 16 января 2010

Этот вопрос касается дизайна проекта. Проект берет электрическую систему и определяет ее функции программно. Теперь, когда я по колено в определении системы, я включаю значительное количество взаимодействия, которое заставляет систему настраивать себя соответствующим образом. Пример: система открывает и закрывает электрические контакторы, когда происходят определенные события. Поскольку эта система находится на самолете, она опирается на логику воздуха / земли и, таким образом, включает в себя два различных поведения в зависимости от того, где она находится.

Я даю все это объяснение, чтобы продемонстрировать уровень сложности, который содержит это приложение. Как я продолжил в своем проекте, я использовал использование конструкций if / else как средство экстраполяции правильных конфигураций в этой электрической системе. Однако чем глубже я углубляюсь в кодирование, тем больше требуется конструкций if / else. Я чувствую, что достиг точки, когда я неэффективно программирую эту систему.

Для тех, кто занимался такими проектами ранее, я спрашиваю: иду ли я по известному пути (когда речь идет об определении КАЖДОГО возможного сценария, который может произойти), и я должен продолжать настаивать ... или я могу использовать некоторые другие стратегии для решения задачи определения поведения реальной системы.

На данный момент у меня практически нет опыта использования делегатов, но мне интересно, смогу ли я использовать некоторые наблюдатели или другие "какао-благие" качества для проверки сценариев вместо бесконечных блоков if / else.

Ответы [ 2 ]

1 голос
/ 18 января 2010

Поскольку вы пытаетесь смоделировать систему реального мира, я бы предложил создать конкретный объектно-ориентированный дизайн, который хорошо определяет отношения «есть» и «есть», применять старый добрый объектно-ориентированный дизайн и применять его для разрушения объекта. система реального мира в функциональной декомпозиции.

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

Например, вы можете иметь много типов событий, привязанных к протоколу ElectricalEvent, и в зависимости от типа вы можете лучше решить, как ElectricalContactor различает GeneralElectricEvent по сравнению с SpecializedElectricEvent, используя селектор isKindOfClass.

0 голосов
/ 16 января 2010

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

Есть несколько реализаций, на которые вы можете посмотреть:

  • SCM позволяет генерировать машинный код состояния для Objective-C
  • OFC реализует их как DFSM

Конечно, вы также можете свернуть свою собственную настраиваемую реализацию, если она вам больше подходит.

...