Pattern bei Embedded Systems verwenden?
-
-
C++ Patterns bei eingebetteten System? Z. B. Observer-, Strategy-Pattern oder Dependency Inversion?
Das ist nicht spezifisch fuer C++. Ich halte Design-Pattern fuer in Regeln gegossener gesunder Verstand.
Dependecy Injection: Module moeglichst entkoppeln. Boah echt krass. Waere ich nie drauf gekommen
Strategy: Funktionen hoeherer Ordnung?
Observer: Da passiert viel zu viel implizit. Write programms not frameworks!
Chain-of-responsibility: naja Prinzip Event-Listener ...
Nullobjekt: Leere List, Maybe oder boost::optional
... kann ich gern fortfuehrenDarueber hinaus sind eingebettete Systeme fuer einen bestimmten Zweck konzipiert. Da werden selten Generalisierungen dieser Art benoetigt bzw. werden weniger objektorientiert umgesetzt.
-
knivil schrieb:
Das ist nicht spezifisch fuer C++.
Ich habe nicht "C++ Patterns" geschrieben, sondern "verwendet jemand in C++ Patterns ... ?"
Ich halte Design-Pattern fuer in Regeln gegossener gesunder Verstand.
Dependecy Injection: Module moeglichst entkoppeln. Boah echt krass. Waere ich nie drauf gekommen
Strategy: Funktionen hoeherer Ordnung?
Observer: Da passiert viel zu viel implizit. Write programms not frameworks!
Chain-of-responsibility: naja Prinzip Event-Listener ...
Nullobjekt: Leere List, Maybe oder boost::optional
... kann ich gern fortfuehrenDarueber hinaus sind eingebettete Systeme fuer einen bestimmten Zweck konzipiert. Da werden selten Generalisierungen dieser Art benoetigt bzw. werden weniger objektorientiert umgesetzt.
Solange du deine Code-Qualität nicht gemessen hast, solange weißt du auch nicht wovon du redest.
Benutze mal structure 101 oder Sonar um bspw. zu sehen, wie modular dein Programm ist. Irgendwelche Back Dependencies drin?
Mit "schnell mal Wikipedia die Begriffe abklappen", ist es nicht getan, um zu wissen, wovon ich rede.L. G.
Steffo
-
Solange du die Standardbibliothek nicht voll mitlinkst sollte C++ kein Problem sein. Wird doch auch nur Maschinencode draus. Wenn du die Sprache kennst, solltest du damit mindestens so gute Programme wie mit C schreiben können, auch für Microcontroller.
-
knivil schrieb:
Dependecy Injection: Module moeglichst entkoppeln.
Was hat Dependecy Injection mit Module entkoppeln zu tun?
-
Bin ich wohl in der Zeile verrutscht ...
Solange du deine Code-Qualität nicht gemessen hast, solange weißt du auch nicht wovon du redest.
Ich brauche dir gar nichts beweisen. Wenn ich Code sehe, erkenne ich, ob er gut bzw. schlecht ist. Wobei das natuerlich auch Geschmackssache ist.
Benutze mal structure 101 oder Sonar um bspw. zu sehen, wie modular dein Programm ist. Irgendwelche Back Dependencies drin?
Alles benutzte wird ueber Header inkludiert. Alles Implizite wird vermieden. Dafuer reicht Doxygen aus.
Mit "schnell mal Wikipedia die Begriffe abklappen", ist es nicht getan, um zu wissen, wovon ich rede.
Es gibt mehr Pattern als im GoF enthalten sind, C++ Idiome und anderes sind auch hilfreich. Und was hilft dir ein Design-Pattern, wenn du einen USB Controller ansteuern musst.
So sieht es bei mir aus: Ich programmiere eingebettete Systeme. Es wird C++ verwendet. Die gelinkte Laufzeitumgebung unterstuetzt alle Features von C++03. Es werden
newunddeletesowie stl-Container benutzt. Meist aber nur bei Systeminitialisierung, spaeter nicht mehr.
-
"Verwenden" ist sicherlich auf kleinen ES schwierig. Vor allem komplexe Pattern benutzen in der Implementierung dann dynamische Datenstrukturen, also etwas, was man auf einem ES anders löst bzw. vermeidet.
Trotzdem schadet es meines Erachtens nicht, die Denkweise auch beim Design eines C-Programms im Hinterkopf zu haben, da sich bei C damit die Struktur des Programms ebenso verbessert. Viele ES-Programmierer bevorzugen ja immer noch so eine Art globales Array, wo alles gespeichert wird, und greifen aus jedem Programmteil kreuz und quer auf die Sachen zu. Allerdings wird die Hardware unter einem ES inzwischen immer komplexer, mehrere Cores, etc, so daß die Tage dieser Art der Programmierung auch gezählt sind.
-
Steffo schrieb:
Benutze mal structure 101 oder Sonar um bspw. zu sehen, wie modular dein Programm ist.
Kenn ich nicht, interessiert mich nicht, werd ich nicht bei Wikipedia nachschlagen. Was ich will ich da messen? Ich weiß, dass der Code bei uns in der Arbeit objektiv zu großen Teilen schlecht ist und sehr viele unnötige Abhängigkeiten enthält. Regt sich jeder drüber auf. So sieht halt die Realität aus. Aber wenn man sich auskennt, kommt man zurecht, und es gibt auch sehr viele aus meiner Sicht sehr elegante und schöne Blöcke und die Qualität wird langsam deutlich besser. Aber da irgendwas zu "messen" geht für mich völlig an der Realität vorbei.
-
Diese Tools zeigen dir wunderbar die Abhängigkeiten und können beispielsweise auch ein stückweit die Komplexität der Software messen und sagen dir auch, an welcher Stelle die Komplexität sehr groß ist. Sie können dir auch sagen was du vermeiden und stattdessen verwenden sollst.
Klar: Manches wird man nach reichlicher Überlegung dennoch nicht ändern wollen, aber unterm Strich sind diese Tools sehr hilfreich.
Du benutzt sicherlich auch valgrind oder Profilingtools. Die von mir genannten Tools stellen eine neue Zäsur in der Informatik dar, weil sie auch die Qualität der Architektur messen können.
-
Marc++us schrieb:
Viele ES-Programmierer bevorzugen ja immer noch so eine Art globales Array, wo alles gespeichert wird, und greifen aus jedem Programmteil kreuz und quer auf die Sachen zu. Allerdings wird die Hardware unter einem ES inzwischen immer komplexer, mehrere Cores, etc, so daß die Tage dieser Art der Programmierung auch gezählt sind.
Daten global zu halten ist oftmals keine Designentscheidung sondern schlicht notwendig, z.B. wenn man über bestimmte etablierte Schnittstellen von aussen auf Daten zugreifen will. Mehrere Kerne oder komplexere Hardware (und Software) ändern an dieser Sache auch erstmal nichts.
-
Diese Tools zeigen dir wunderbar die Abhängigkeiten und können beispielsweise auch ein stückweit die Komplexität der Software messen und sagen dir auch, an welcher Stelle die Komplexität sehr groß ist
Dazu brauche ich kein Tool.
Sie können dir auch sagen was du vermeiden und stattdessen verwenden sollst.
Denken kann ich alleine. Aber du weichst aus. In welcher weise koennen sie mir bei eingebetteten Systemen helfen?
Du benutzt sicherlich auch valgrind oder Profilingtools. Die von mir genannten Tools stellen eine neue Zäsur in der Informatik dar, weil sie auch die Qualität der Architektur messen können.
Die eine sind nuetzlich fuer Entwickler, die anderen muessen sich erst beweisen.
Thus spake the master programmer:
``When the program is being tested, it is too late to make design changes.''
Was hilft es hinterher festzustellen, wenn der Code scheisse ist?
-
Steffo schrieb:
Diese Tools zeigen dir wunderbar die Abhängigkeiten und können beispielsweise auch ein stückweit die Komplexität der Software messen und sagen dir auch, an welcher Stelle die Komplexität sehr groß ist. Sie können dir auch sagen was du vermeiden und stattdessen verwenden sollst.
Klar: Manches wird man nach reichlicher Überlegung dennoch nicht ändern wollen, aber unterm Strich sind diese Tools sehr hilfreich.
Du benutzt sicherlich auch valgrind oder Profilingtools. Die von mir genannten Tools stellen eine neue Zäsur in der Informatik dar, weil sie auch die Qualität der Architektur messen können.Ich verstehe, was du sagen willst, bin aber nicht wirklich überzeugt davon. Ich sehe darin keinen praktischen Nutzen. Es geht vielleicht bei kleineren oder mittelgroßen Projekten, wenn überhaupt. Wenn ich ein überschaubares Programm geschrieben habe und die Software sagt mir, hier sind evtl. zu viele Abhängigkeiten, sag ich doch blöde Software, lass mich in Ruhe, ich will das genau so haben. In der Arbeit haben wir ein 6 Mio Lines of Code Projekt mit sehr vielen hässlichen Klassen und Abhängigkeiten. Es gibt zentrale Klassen, die hat jemand vor 15 Jahren geschrieben, da sind vielleicht jeweils 20k Zeilen in einer Klasse, völliger Irrsinn. Und die Klassen benutzt jeder, weil er sie eben benutzen muss. Was bringt da jetzt eine Software oder eine Metrik, die sagt, das ist schlecht? Wir haben schon mal gar keine Zeit und keine Ressourcen, das besser zu machen. Aber wenn, müssten sich erstmal so 20 Leute zusammensetzen und die Anforderungen neudefinieren. Dieser ganze alte Kern gehört neugeschrieben, damit müsste sich aber die Art, wie er benutzt wird, komplett ändern und dazu müsste man an sehr vielen Stellen in der Software was anpassen. Ist geplant, ist im Moment aber nicht drin und da hilft auch deine Software nichts. Man muss einfach eine gescheite Architektur entwerfen. Und ob die Abhängigkeiten so gut sind oder nicht, versteht ein Mensch immer noch 1000 mal besser als eine Software. Und wenn nicht, wird er das auch nicht ändern wollen, weil es ihm so einfach gefällt, es sonst zu viel Aufwand wäre, schlecht für die Performance oder sonst was...
-
Ich hatte mal ein Projekt wo der microkontroller auch mit c++-programmiert werden konnte. da hab ich dann mit dem state-pattern gearbeitet. Das hat auch nicht so viele Bytes gekostet. Ansonsten hab ich schon drauf geachtet, nur c++-features zu nehmen die nix kosten aber viel bringen (namespaces etc.)