Sauber objektorientiert Programmieren; Brauche kleine Hilfestellung

Luigi schrieb:
> Was ich nun allerdings überlege, ist ob es sinnvoll ist für jedes
> Kommando ein Objekt von einem Basis-Paket abzuleiten, oder ob es
> sinnvoller ist, diese Basiskommandos über Parameter zu "konfigurieren"?

Das erste klingt für mich grundsätzlich vernünftig. Etwas ähnliches habe 
ich auch auf einem µC implementiert, aber den ganzen Klassenoverhead 
weggelassen. Dort gibt es aber auch eine allgemeine 
Paket-Parsing-Funktion. Die checkt dann erstmal, ob ein gültiges Paket 
vorhanden ist, also bei mir ob die Checksumme passt, ob die Länge passt, 
ob das Kommando existiert. Dann wird ein Funktionspointer aufgerufen je 
nachdem welches Kommando gesendet worden ist. Übertragen auf den PC wo 
Overhead egal ist würde ich dann in die abstrakte Basisklasse sowas wie 
Checksum- und Längenprüfung machen.

Den zweiten Ansatz verstehe ich aber nicht wirklich. Das funktioniert 
doch immer nur dann wenn die Kommandos ähnlich vom Aufbau sind. Aber 
wenn zB zwischen Messdaten oder aber Debugstrings unterschieden werden 
soll, skaliert das meiner Meinung nicht. Das endet dann in einer 
riesigen if-else-whatever-Struktur die über kurz oder lang 
unübersichtlich werden wird.

Luigi schrieb:
> oder ob es
> sinnvoller ist, diese Basiskommandos über Parameter zu "konfigurieren"?

Wenn man sowas baut

1

enum eMsgType{ELEPHANT, CHEESE, BURN};

2

3

struct Message

4

{

5

    eMsgType type;

6

    uint8_t data[16];   

7

};

und jede Funktion mit

1

void do_things(const Message& msg)

2

{

3

    switch(msg.type)

4

    {

5

        case ELEPHANT: toeroeh(*(ElephantContent*)msg.data); break;

6

        case CHEESE: ........

anfängt, macht man es falsch. Das kann der Compiler besser. Und wenn 
das, was man machen will, zu kompliziert ist, um es in Polymorphismus zu 
verpacken, dann ist es zu kompliziert und muss überarbeitet werden.

Wenn man aber die Message-Struktur um einen Callback und eine (im 
Kommando übertragene) TelegrammID erweitert, sieht's schon freundlicher 
aus. Dann kann man beim Empfang einer Antwort auch gezielter reagieren.

Luigi schrieb:
> Nun habe ich mir ein "Objekt" geschrieben, welches quasi die serielle
> Schnittstelle darstellt und Pakete/serille Kommandos verwaltet

Nun, genau das ist eigentlich der falsche Ansatz.

Objektorientiert programmiert man, wenn man eine Anzahl von innerlich 
zwar unterschiedlichen, in der äußeren Behandlung jedoch gleiche Dinge 
(eben Objekte) hat. Grafisches Zeug auf dem Bildschirm ist ein typisches 
Beispiel: ob Liste odr Button oder Icon, alle müssen sich auf Kommando 
selbst darstellen und auf Input reagieren - egal was sie innerlich sind.

Bei einem Handler für ne serielle Schnittstelle hingegen kann und sollte 
man schlichtweg prozedural vorgehen - allerdings in separatem Thread. 
Immerhin ist es ja so, daß da eben nix anderes ankommt als ein serieller 
Bytestream, den es nach irgendwelchen Kriterien zu kanalisieren und zu 
ordnen gilt. Die Schnittstelle selbst ist kein Objekt im eigentlichen 
Sinne, denn es gibt ja nicht eine Vielzahl davon, die alle zugleich in 
Aktion sind.

Erst oberhalb des o.g. Handlers wäre wieder an Objekte zu denken, also 
wenn es zuvor einen vom Handler in die Queue geworfenen Event nebst 
Datensatz gibt, der dann zum Kreieren eines Objektes führt. Aber das ist 
dann schon unabhängig von allen seriellen oder sonstigen Schnittstellen.

W.S.

W.S. schrieb:
> Bei einem Handler für ne serielle Schnittstelle hingegen kann und sollte
> man schlichtweg prozedural vorgehen - allerdings in separatem Thread.
> Immerhin ist es ja so, daß da eben nix anderes ankommt als ein serieller
> Bytestream, den es nach irgendwelchen Kriterien zu kanalisieren und zu
> ordnen gilt. Die Schnittstelle selbst ist kein Objekt im eigentlichen
> Sinne, denn es gibt ja nicht eine Vielzahl davon, die alle zugleich in
> Aktion sind.

nein

Eine Schnittstelle ist sehr gut als Objekt verwendbar. (Was übriges in 
viele Sprachen auch so gemacht wird).
Warum sollte man viele Prozeduren schreiben, die alle das Handle 
übergeben bekommen? Eventuell muss ja auch noch der Status verwaltet 
werden (verbunden - nicht verbunden) Wo willst du den denn speichern? 
Also zu jedem Handle auch noch ein haufen Variablen?

Machs erst mal prozedural soweit, bis alles funktioniert wie gewünscht.
Es handelt sich ja nur um eine Schnittstelle. Wenn du dann noch viel 
Motivation hast, kannst Du ja das kompakte, funktionierende Programm in 
eine OOP Scheisse umbauen und dann feststellen, daß Du den zwanzigfachen
Code / Overhead und keinerlei Vorteil davon hast. Also wozu ?

OK, vielen Dank Leute.
Ihr habt mir viel geholfen. Damit ist dann meine Entscheidung gefallen, 
wie ich weiter mache (vererben).
Alles Andere ist in der tat nicht so recht zu ende gedacht und "mal 
drauf los"-programmiert. Letzteres ist zwar mehr mein Stil, weil ich es 
nie anders gelernt habe, aber zumindest abschnittsweise kann ich mir 
Konzepte ausdenken ;)

Ob ich noch der große Programmierer werde, wage ich zu bezweifeln, aber 
ich komme meistens ans Ziel. Und immerhin habe ich den Ansporn mich zu 
verbessern.
Die Objektorientierung so verstehen, wie es manche glauben besser zu 
wissen, wird für mich jedenfalls noch ein Meilenstein sein. Ich lerne 
aber zunehmend schon jetzt die Vorzüge dieser (objektorientierten) 
Hilfsmittel zu meinen Gunsten zu verwenden.

Vielen Dank nochmals
Grüße Luigi

OOP Blähware Hasser schrieb:
> Machs erst mal prozedural soweit, bis alles funktioniert wie gewünscht.
warum erst umständlich machen und dann vereinfachen?

> Es handelt sich ja nur um eine Schnittstelle.
Es ist auch nur ein Programm, auch da verwendet man mehrere Objekte.

> Wenn du dann noch viel
> Motivation hast, kannst Du ja das kompakte, funktionierende Programm in
> eine OOP Scheisse umbauen und dann feststellen, daß Du den zwanzigfachen
> Code / Overhead und keinerlei Vorteil davon hast. Also wozu ?
Achso darum geht es, du willst es nur nicht.

Woher der Overhead kommen soll ist mir nicht klar. Ein Objekt was intern 
nur ein Handle hat, hat auch nur die Größe von einen Handle und die 
Methoden sind auch gleich groß.

Luigi schrieb:
> Alles Andere ist in der tat nicht so recht zu ende gedacht und "mal
> drauf los"-programmiert.

Erstmal (grob gezielt) drauf los und sehen, was herauskommt, ist bei 
komplexen Problemen, die man noch nicht ganz versteht (also bei jedem 
größerem Programm), vollkommen OK.
Man muss nur zwischendurch (nach jedem eingebauten Feature) regelmäßig 
das bisher geschaffene analysieren, herausfinden, wie es besser ginge, 
und dann auch gnadenlos umbauen. Basisklassen, Pattern etc. ergeben sich 
dann teilweise von selbst. Und keine Scheu haben, alten Code (egal wie 
viel Arbeit drinsteckt) neuzuschreiben (oder im besten Fall ganz zu 
löschen), wenn das Gesamtsystem übersichtlicher wird. Wenn man um die 
alten Fehler (die mal gute Ideen waren und sich erst später als 
ungünstig erwiesen haben) herumprogrammiert, hat man dank 
Schneeballeffekt irgendwann einen undurchschaubaren unwartbaren 
Misthaufen.

W.S. schrieb:

> Bei einem Handler für ne serielle Schnittstelle hingegen kann und sollte
>    man schlichtweg prozedural vorgehen - allerdings in separatem Thread

Das ist mir IMHO eine falsche Verallgemeinerung. Warum soll ein eigener 
Thread erzeugt werden...? Das hat mit der Frage nix zu tun.

Ja, ein Thread macht Sinn, wenn daa Senden und Empfangen nicht 
blockieren sein darf, aber diese Info hat der TO nicht geliefert. Wenn 
die Schnittstelle nach dem Prinzip Request/Response arbeitet, macht ggf 
ein eigener Thread keinen Sinn.

Was mir immer wieder auffällt, egal ob prozedural oder OOP programmiert 
wird: immer wird eine Lösung diskutiert oder ein Design erstellt, bevor 
ueberhaupt die Aufgabe dargestellt ist und die möglichen Probleme 
identifiziert...

Noch schlimmer ist es beim Entwurf eines Gerätes:

Die Hardwareker designern sofort Hardware, die Softwareker sofort 
Software. Dabei ist das zuerst zweitrangig. Erst muss mal die Funktion 
erfasst werden...