:strip_icc():strip_exif()/u/419131/crop647054edc1b07_cropped.jpg?f=community)
Hallo beste mede-tweakers!
Ik zit een beetje te kijken naar Rust en tot nu toe ziet het er goed uit.
Het is mogelijk dat ik een C++ systeem ga herschrijven hierin als het goed genoeg wordt bevonden. Nu heb ik alleen voornamelijk ervaring met OOP en maar weinig met talen die dat niet hebben. Vandaar dat ik jullie wil vragen wat jullie hier van denken.
Het huidige systeem ziet er als volgt uit:
Het draait embedded op een microcontroller.
De hardware configuratie kan verschillen, maar de codebase is hetzelfde.
Het is dus belangrijk dat bepaalde taken op verschillende manieren uitgevoerd kunnen worden.
Hiervoor is de service uitgevonden met hieronder een voobeeldje.
Naast de communicationservice zijn er nog meer service 'types'. En al die types hebben meerdere implementaties. Zo kan er voor de CommunicationService ook een UdpCommunicationService of een BluetoothCommunicationService implementatie zijn.
Van elke service type wordt er één implementatie geïnstantieerd en gebruikt voor de werking van het systeem. Het systeem accepteert dus een CommunicationService instance, waarbij het niet uitmaakt welke implementatie die volgt (zolang die maar correct is natuurlijk). Het volgt dus het principe van Dependency Injection.
Het voordeel van dit systeem is dat een implementatie zich niet druk hoeft te maken over de EEPROM en de status. Dit (onder andere) zorgt ervoor dat een programmeur makkelijk een nieuwe service kan schrijven zonder de rest van het systeem (uitgebreid) te hoeven kennen.
Nu dus de omzetting naar Rust.
Ik denk dat er twee mogelijkheden zijn: Trait inheritance en function callbacks.
1. Trait inheritance
Voor zover ik nu kan begrijpen zijn traits (bijna) net zoals interfaces in C#/Java/C++.
Het zou dus mogelijk zijn om alle abstract methods te vervangen met functies gedefinieerd in de traits.
De service trait zou dan dezelfde functions hebben als de abstract methods in C++.
De code voor de EEPROM e.d. kan een aparte struct zijn die via een getters en setters in de trait te benaderen zijn.
De inheritance is dan ook door te zetten naar de children.
Hoewel ik denk dat dit systeem prima kan werken, voelt dit te OOP aan en lijkt het niet bij Rust te passen. (Of zit ik hier verkeerd?)
Een nadeel aan dit systeem is dat elke service implementatie ook nog zelf de variabelen voor EEPROM e.d. moet declareren en de getters en setters moet implementeren. Hoewel dat niet een groot probleem is, is het wel irritant om te moeten doen en ook niet zo clean omdat elke service die code gedupliceerd zal hebben.
2. Function callbacks
Omdat er van elke service type maar één actief gaat zijn, is het misschien een idee om van het concept af te stappen. De inheritance is namelijk vooral bij compile-time nodig in het huidige systeem en niet in de runtime. Het systeem hoeft alleen maar te weten hoe die data moet versturen en ontvangen.
Het systeem kan ook een aantal function callbacks vrijgeven die het aanroept wanneer er iets verstuurd moet worden enzo.
In plaats van een struct instance aan het systeem te geven bij het configureren, roep je iets aan als Tcp::configure_system_for_tcp.
Ook dit zou kunnen werken, maar ik vrees dat dit makkelijk onoverzichtelijk te maken is. Maar zoals al eerder gezegd, heb ik hier niet veel ervaring mee.
Wat zijn jullie gedachten hierover?
Zie ik iets over het hoofd of zit ik wel in de buurt?
Hoe dan ook, bedankt voor et lezen en meedenken.
Ik zit een beetje te kijken naar Rust en tot nu toe ziet het er goed uit.
Het is mogelijk dat ik een C++ systeem ga herschrijven hierin als het goed genoeg wordt bevonden. Nu heb ik alleen voornamelijk ervaring met OOP en maar weinig met talen die dat niet hebben. Vandaar dat ik jullie wil vragen wat jullie hier van denken.
Het huidige systeem ziet er als volgt uit:
Het draait embedded op een microcontroller.
De hardware configuratie kan verschillen, maar de codebase is hetzelfde.
Het is dus belangrijk dat bepaalde taken op verschillende manieren uitgevoerd kunnen worden.
Hiervoor is de service uitgevonden met hieronder een voobeeldje.
code:
1
2
3
4
5
6
7
8
9
10
11
| Service * Methods en variabelen voor het opslaan van service data in EEPROM * Methods en variabelen voor de status van de service * Abstract methods voor starten en stoppen CommunicationService : Service * Abstract methods om bepaalde communicatie taken mee uit te kunnen voeren TcpCommunicationService : CommunicationService * Uitwerkingen van alle abstract methods * Eigen variabelen en methods voor Tcp communicatie |
Naast de communicationservice zijn er nog meer service 'types'. En al die types hebben meerdere implementaties. Zo kan er voor de CommunicationService ook een UdpCommunicationService of een BluetoothCommunicationService implementatie zijn.
Van elke service type wordt er één implementatie geïnstantieerd en gebruikt voor de werking van het systeem. Het systeem accepteert dus een CommunicationService instance, waarbij het niet uitmaakt welke implementatie die volgt (zolang die maar correct is natuurlijk). Het volgt dus het principe van Dependency Injection.
Het voordeel van dit systeem is dat een implementatie zich niet druk hoeft te maken over de EEPROM en de status. Dit (onder andere) zorgt ervoor dat een programmeur makkelijk een nieuwe service kan schrijven zonder de rest van het systeem (uitgebreid) te hoeven kennen.
Nu dus de omzetting naar Rust.
Ik denk dat er twee mogelijkheden zijn: Trait inheritance en function callbacks.
1. Trait inheritance
Voor zover ik nu kan begrijpen zijn traits (bijna) net zoals interfaces in C#/Java/C++.
Het zou dus mogelijk zijn om alle abstract methods te vervangen met functies gedefinieerd in de traits.
De service trait zou dan dezelfde functions hebben als de abstract methods in C++.
De code voor de EEPROM e.d. kan een aparte struct zijn die via een getters en setters in de trait te benaderen zijn.
De inheritance is dan ook door te zetten naar de children.
Hoewel ik denk dat dit systeem prima kan werken, voelt dit te OOP aan en lijkt het niet bij Rust te passen. (Of zit ik hier verkeerd?)
Een nadeel aan dit systeem is dat elke service implementatie ook nog zelf de variabelen voor EEPROM e.d. moet declareren en de getters en setters moet implementeren. Hoewel dat niet een groot probleem is, is het wel irritant om te moeten doen en ook niet zo clean omdat elke service die code gedupliceerd zal hebben.
2. Function callbacks
Omdat er van elke service type maar één actief gaat zijn, is het misschien een idee om van het concept af te stappen. De inheritance is namelijk vooral bij compile-time nodig in het huidige systeem en niet in de runtime. Het systeem hoeft alleen maar te weten hoe die data moet versturen en ontvangen.
Het systeem kan ook een aantal function callbacks vrijgeven die het aanroept wanneer er iets verstuurd moet worden enzo.
In plaats van een struct instance aan het systeem te geven bij het configureren, roep je iets aan als Tcp::configure_system_for_tcp.
Ook dit zou kunnen werken, maar ik vrees dat dit makkelijk onoverzichtelijk te maken is. Maar zoals al eerder gezegd, heb ik hier niet veel ervaring mee.
Wat zijn jullie gedachten hierover?
Zie ik iets over het hoofd of zit ik wel in de buurt?
Hoe dan ook, bedankt voor et lezen en meedenken.