Processi orientati agli oggetti e procedurali nel sistema integrato

3

Attualmente sto sviluppando un controller per un'applicazione industriale che prende gli input di dati da vari sensori e interfacce (ethernet, seriali, ecc.), esegue un minimo di elaborazione e adatta le uscite alle interfacce e ai sistemi meccanici secondo necessità.

Il dispositivo, un controller di automazione B & X20, utilizza un semplice RTOS che funziona su un single-core con supporto multi-processing, ma non multi-threading. Non è possibile generare nuovi processi durante l'operazione. Gli interrupt non sono supportati. Piuttosto, per assegnare la priorità alle attività, ogni processo viene assegnato durante la programmazione di una frequenza per l'esecuzione completa del suo ciclo principale e lo scheduler fa del suo meglio per aderire a questo programma in tempo reale, generando eccezioni in caso di violazioni temporali.

Per massimizzare la concorrenza tra le varie funzioni, ognuna delle quali ha requisiti di temporizzazione diversi, ho diversi piccoli processi (ad esempio, un lettore / scrittore ethernet, un apriporta / chiudi valvola) per lo più associati 1-a-1 con input / output funzioni. Per soddisfare i requisiti di I / O in tempo reale, l'elaborazione intensiva dei dati viene eseguita in processi separati, prescritti per ridurre la frequenza di pianificazione.

La comunicazione tra processi avviene attraverso variabili globali ai rispettivi processi, sincronizzati tramite semafori.

Il dispositivo consente di scrivere programmi in C e C ++. Quando dovrei preferire scrivere con uno o l'altro? Non supponiamo alcuna differenza significativa nelle prestazioni.

Il mio pensiero:

Mentre il mio istinto è di preferire l'incapsulamento del C ++, ciascuno dei miei processi è sufficientemente semplice in modo tale che l'uso di OOP lascerebbe in esso un solo oggetto. La codifica in C ++ sembra quindi aggiungere un ulteriore livello di comunicazione inutile dall'oggetto al processo: le variabili globali che non esisterebbero sarebbero state l'oggetto di calcolo senza dimora. Inoltre, poiché l'intero processo contiene un oggetto, sembra che non vi sia alcun beneficio di incapsulamento, dal momento che non è rimasto nulla da incapsulare.

Allo stesso tempo, ho l'istinto che anche i programmi semplici dovrebbero essere programmati con OOP quando possibile per consentire flessibilità e crescita.

Ho scoperto una situazione in cui l'oggettificazione introduce livelli di struttura non necessari a un programma semplice? O è preferibile aderire a OOP ogni volta che l'hardware lo consente?

    
posta Dragonsheep 07.08.2018 - 04:56
fonte

2 risposte

4

C e C ++ sono strettamente correlati. La loro principale differenza non è quella procedurale e l'altra orientata agli oggetti. La differenza principale è che C ++ offre un sistema di tipo molto più espressivo (incluso il supporto per OOP, ma non si è mai costretti a usarlo).

In effetti, molti programmi non hanno bisogno di alcun tipo di OOP. Con OOP, qui intendo specificamente metodi virtuali e RTTI che implicano alcuni costi di runtime. Se stessimo scrivendo C, probabilmente usereste invece i puntatori di funzione o i sindacati taggati. Le funzionalità di C ++ come la parola chiave class o l'accesso private sono concetti correlati, ma sono utili anche senza OO. Vuoi comunicare attraverso variabili globali? C ++ ti consente di farlo senza costringerti a creare classi. Una progettazione procedurale è spesso completamente valida.

Nella mia esperienza, scegliere C ++ è quasi sempre la scelta migliore, se hai la possibilità. Ottieni varie funzionalità come:

  • distruzione deterministica / RAII , che elimina una fonte comune di bug
  • modi migliori per strutturare il codice, inclusi spazi dei nomi, visibilità dei membri privati, costruttori, metodi / funzioni dei membri, ...
  • probabilmente una grande libreria standard (probabilmente non quando è incorporata)
  • possibili eccezioni (probabilmente non in un contesto incorporato)
  • modelli , come un tipo di macro sicura dal tipo
  • piccole cose, come riferimenti o quel carattere letterale 'a' in realtà ha tipo char
  • C ++ 11: molti miglioramenti della qualità della vita come auto , lambdas, using e così via.
  • compatibilità quasi completa con la sintassi C

Puoi letteralmente prendere la maggior parte dei programmi C e compilarli come C ++. Se è necessario mantenere la compatibilità ABI, spesso è sufficiente aggiungere alcune dichiarazioni di extern "C" . Il percorso di aggiornamento è molto semplice e ti offre tantissime funzionalità extra. Puoi decidere quanto lontano vuoi andare: è perfettamente valido scrivere molto C-ish C ++ che usa solo alcune funzioni extra.

Ma ci sono ancora dei motivi per cui potresti voler usare C:

  • C è un linguaggio molto più semplice.
  • Più persone conoscono C che C ++ (importante se altre persone dovranno lavorare con il tuo codice).
  • C è più portabile (irrilevante se si targetizza un compilatore specifico su una piattaforma specifica).

Non lasciare che il tuo design guidi la tua scelta tecnologica troppo lontano. Se si desidera utilizzare un design orientato agli oggetti, C ++ semplifica l'implementazione di tale progetto, ma non è necessario. Viceversa, C ++ potrebbe essere ancora attraente anche per un disegno procedurale. Alla fine questa scelta linguistica è in gran parte una questione di preferenze personali: se pensi che il tuo codice sarà più semplice se sarai in grado di creare forti astrazioni (C ++) o se preferisci mantenere il codice semplice, esplicito e ovvio (C ).

    
risposta data 07.08.2018 - 23:18
fonte
3

Ho una certa esperienza limitata nella programmazione embedded, principalmente con Arduino-compatibili, ESP8266, quel tipo di cose e solo per divertimento.

Ho iniziato con le librerie disponibili, tutte procedurali, devo dire, ma mi sono rapidamente ritrovato a implementare nuovamente tutto in OO / C ++, solo per poter collegare le cose più facilmente.

Quindi i miei punti sono:

  • Non esiste un "programma semplice". Non se mai vuoi leggere di nuovo il tuo codice. Anche per un semplice pulsante che accende una luce, ci sono già più oggetti.

  • Informazioni sull'introduzione di "livelli non necessari di strucutre". Non si introduce la struttura solo per il gusto di farlo. Ok, alcune persone credo. La struttura che introduci è sempre lì per codificare conoscenza del dominio. Conoscenza che documenti per il tuo lettore .

La struttura che introduci è fondamentalmente come una documentazione per sviluppatori per il tuo codice, eccetto che è immediatamente compresa da tutti e si applica da sola.

Penso che potresti avere paura di OO, perché abilita i livelli di over-engineering, a volte persino ridicolo (vedi Java Enterprise). Lo fa proprio perché consente di gestire meglio la complessità, quindi alcune persone compensano introducendo più complessità. Se sei consapevole di questo e puoi resistere a questo, tu e il tuo design oo andrà bene, e sarà più leggibile e manutenibile.

    
risposta data 07.08.2018 - 11:19
fonte