Verständnis OOP für hardwarenahe Programmierer

@netdieter

Kannst du ein paar Worte dazu verlieren, ich verstehe nicht was du damit 
meinst? Wenig ist doch zumindest etwas.

Tach

VBA kenn ich zu wenig. Ich lernte OO mit Hilfe von Java. Dazu sind im 
Internet viele Artikel zu finden, wo die denkweise von OO vermittelt 
wird.

gruss

Danke für die bisherigen Antworten, hat vielleicht noch Jemand ein paar 
konkrete Tipps für mich? Oder habe ich mich zu unklar ausgedrückt?

http://openbook.galileocomputing.de/javainsel8/

oder

Java von Kopf bis Fuss (relativ spielerisch aber gut verständlich)

villeicht hilft auch disenda weiter

http://openbook.galileocomputing.de/oop/

ich selber habe oop mit java gelernt, unteranderem auch mit hilfe von 
"java ist auch eine insel"

Ja. OOP hat mit hardwarenah sehr wenig zu tun. Dies weil OOP als 
dynamische Speicherorgie beginnt und mit einem Garbage Collector endet. 
Beides ist nicht Echtzeitfaehig. Wenn das Programm mal schnell eine 
Warteschlange instanzieren sollte, der dynamische Speicher aber grad 
nicht verfuegbar ist, muss der Garbage Collector anspringen und das 
aendern - schwups das Ereignis ist leider schon vorbei. Solche Dinge 
laesst man lieber sein und alloziert den Speicher statisch zu Powerup.

@Aahh
Klaus hats ja schon geschrieben, der Garbage-Collector ist kein fester 
Bestandteil von OOP. Trotzdem war dein Beitrag für mich interessant, 
danke dafür.

@Klaus
Ja, die Frage ist offensichtlich nicht so einfach zu beantworten. Das, 
was ich an OO in Assembler/C auf einem uC hinbekomme, bringt mir für das 
Verständnis der VBA-Umgebung nicht viel.

Kann noch wer zur "VBA-Denkweise" was schreiben? Sollte ich mich zuerst 
näher mit Windows an sich befassen?

>nebenbei: was meinst du, wenn du von deinen "objektorientiert
>aufgebauten Funktionen" sprichst?
>Das kann ich mir nur schwer vorstellen...

Das 'objektorientiert' steht nicht umsonst in Anführungseichen. Du 
kennst z.B. CAN, man spricht dort von einem objektorientierten Modell. 
Das hat mit OOP ja auch nichts zu tun, mit meinen angesprochenen 
Funktionen verhält es sich analog:

Wenn ich mir z.B. am uC eine Softkey-Tastatur programmiere, die 
verschiedene Bedienarten (Klick, Doppelklick, langes Halten) 
unterstützt, denke ich objektorientiert und schreibe meine Funktionen 
dann so. Ich weiss, dass das konkret nichts mit OOP zu tun hat.

Aber nochmal, ich brauche kein OOP für uC sondern bin auf der Suche nach 
einer generellen Einführung in die Thematik, die ein bischen mehr die 
Híntergründe ausleuchtet. Damit ich verstehe, wie lang welches Objekt 
wie viel Speicher benötigt, usw. usf.

>es ist eine alte Mär, dass embedded und C++ nicht zusammen apassen

Ja, das mag stimmen. Ich wollte aber nicht philosophieren sondern eine 
Quelle, die mir z.B. dies hier in Bezug auf VBA erklärt:

>Überlade ich aber new und delete klassenspezifisch, kann ich
>Speicherfragmentierung verhindern, statischen Speicher verwenden und die
>Performance drastisch steigern.

Also wie realisiere ich Überladungen, wann und wofür brauche ich sie, 
muss ich Klassenmodule schreiben oder reicht es die bereits in VBA 
enthaltenen Klassen/Objekte zu kennen etc....

Meinen new und delete in Bezug auf jedes Objekt das Gleiche?

Ein gutes Buch kann ich empfehlen "Object-Oriented Analysis and Design 
with Applications". Ist auch ziemlich nahe an der Hardware. Zumindest 
die 2nd Edition ist noch in C++. Aber Crash-Kurs ist nicht. OOP zu 
verstehen ist meiner Meinung nach relativ komplex. Wenn man schon 
einiges mit C/ASM gemacht hat ist es für die meisten sogar noch 
schwieriger die Konzepte zu verstehen. Ich habe mehrere Jahre gebraucht. 
Vielleicht geht es auch schneller - aber ich habe auch schon jede menge 
Code von Pseudo-Java Entwicklern gesehen die mit OOA/D/P an sich nicht 
sehr viel zu tun hatten.

Manuel:
>Wenn man schon einiges mit C/ASM gemacht hat ist es für die meisten sogar
>noch schwieriger die Konzepte zu verstehen.

Das glaube ich sofort.

Klaus:
>bist du jetzt konkret auf VBA fixiert?

Ja, leider. Hätte ich wohl schon im Betreff erwähnen sollen, sorry.

Olaf:

Vielen dank, dass du dir Zeit genommen hast.

>Dir ist doch der Unterschied zwischen Objekt und Klasse vertraut?

Nicht zu hundert Prozent, glaube ich. Ich werde noch ein bischen 
Grundlagen wälzen um morgen zielführende Fragen zu stellen. Da ich 
morgen früh raus muss, lass ich das jetzt mal so stehen.

Also lass mal das hardwarenah und das VBA weg, beides hat keinen Bezug. 
Was ist objektorientiert ?
1)Daten und Code gehoeren zusammen und bilden ein Objekt.
  Der Code existiert einmal, die Daten werden fuer jede
  Instanz angelegt
2)Die Daten des Objektes werden nicht global zugegriffen,
  sondern eingkapselt mit Zugriffsprozeduren zugegriffen.
  Ein Konstruktor is Pflicht, ein Destruktor meist auch.
3)Vererbung bedeutet weitergehende spezialisierung, indem
  einem Objekt zusaetzliche Variablen, zusaetzliche
  Funktionalitaet durch zusaetzliche Zuriffsprozeduren
  verpasst werden.

Eine Klasse nennt sich das Strickmuster, ein Objekt ist
der dazugehoerige Pullover.

Hallo Mark,

sicher, ist lustig, OOP in Assembler ;) Würde mich aber freuen wenn du 
auch was zum Thema sagen könntest.

@Klaus

Ist die Aussage so zu verstehen, dass ein Objekt einen Satz Variablen, 
die zu einem Stück Code (Objekt-Code?) gehören im RAM anlegt? Also für 
jede Instanz des Objekts eine feste Anzahl an Bytes/Words, oder variiert 
dies je nach Verwendung im weiteren Code?

vza:
>Wann mach OOP Sinn?

Danke für die kleine Ausführung zu diesem Punkt. Mit solchen Erklärungen 
kann ich viel anfangen, das gibt mir ein wenig Einblick in die Denkweise 
von OO-Programmierern.

>Auch Kapselung ist unter C möglich, wenn man sich abgewöhnt auf
>Variablen andere Module direkt zuzugreifen.

Mit solchen Dingen bin ich vertraut, mein Problem ist wirklich die 
spezielle Natur von VBA, das, wie du richtig anmerkst, eine 
Scriptsprache für Office ist.

>Mein Tipp: Spiel ein bischen mit Java oder C# auf dem PC herrum, völlig
>losgelöst von µC oder c/asm.  Wo bei die Beispiele die Themen
>Klasse/Instanzen, Vererbung, Überladung, Templates, abstrakte Klassen
>beinhalten solten.

Werd ich mir zu Herzen nehmen, danke für den Tipp. Noch eine Frage dazu: 
du empfiehlst C#, wo siehst du einen Vorteil gegenüber C++?

@Karl heinz Buchegger

Schön beschrieben.

Was mich dazu interessieren würde ist, wer schreib OO-Code in C++ für
AVR´s und was sind eure Erfahrungen ?

remmy

kbuchegg:

Danke dass du dich meiner Frage angenommen und sie so ausführlich 
beantwortet hast.

>(In C++ kann man sich eine 'Klasse' wie den Bauplan eines Hauses
>vorstellen. Die Klasse ist der Plan, das tatsächlich vorhandene Haus ist
>ein Objekt dieser Klasse. Von einem Plan ausgehend kann man viele Häuser
>bauen, die zunächst alle gleich sind, aber dann vom Bewohner individuell
>abgeändert werden)

Ok, so habe ich mir das auch vorgestellt. Oben kam ja schon die Analogie 
Strickmuster(Klasse) und Pullover(Objekt), die ich auch sehr plastisch 
finde. Das Beispiel mit den Häusern macht es aber einfacher, mein 
Probmlem zu verdeutlichen:

Wie in der Realität benötigen unsere 'Häuser' ja Platz, der 'Baugrund' 
ist in dem Fall mein RAM. Sind die Konzepte, die mir die Verwaltung des 
Baugrunds ermöglichen, in allen OOP-Sprachen gleich umzusetzen oder ist 
das Plattform-Abhängig? (die Plattform stellt ja den 'Baugrund' 
physikalisch bereit)

Unabhängig davon, wie ich das speziell in VBA realisieren muss: Bleiben 
wir weiter bei OOP im Allgemeinen oder einem der OOP C-Dialekte, ich 
glaube das hilft mir wirklich weiter. :)

@remmy

Machst du bitte einen eigenen Thread dazu auf? Wir entfernen uns hier 
langsam aber sicher von der Verbindung OOP zu Mikrocontrollern. Da ich 
diesen Thread auch gerne lesen würde, freue ich mich wenn du das 
wirklich tust. :)

Natürlich kann man sich das so gut vorstellen. Real wird man so aber 
nicht zum OOP. Außerdem ist das was der OP als Aufgabe beschreibt 
eigentlich schon als Teil des VBA-Framework vorhanden. Ich denke nicht 
das es besonders viel Sinn macht hier über OOA/D/P Techniken 
nachzudenken. Die Aufgabe ist ja eher trivial. Ein OO Ansatz ist hier 
IMHO (zumindest für den OP) falsch.

Manuel:

Das VBA-Framework greift doch auf OOP zurück oder nicht? Du hast recht 
mit deiner Anmerkung, dass die bisher geführte Diskussion nicht auf 
meine Aufgabe abzielt - das muss sie aber auch nicht. Ich finde die 
Thematik OOP recht inspirierend, auch wenn ich für meine Aufgabe einen 
VBA-Kurs bräuchte. Ich möchte in Zukunft nicht immer auf VBA 
zurückgreifen, daher gefallen mir die bisherigen Beiträge sehr gut. 
Sollte ich bei der Umsetzung meiner 'eigentlich trivialen' Aufgaben 
Probleme bekommen, werde ich einen VBA-Thread hier oder in einem 
VBA/VB-Forum starten.

@Alle

Danke für die vielen Beiträge, wenn jetzt niemand mehr was einfällt 
lassen wir das mal so stehen. Nächstes mal werde ich mich um einen 
passenderen Betreff und klarere Fragen bemühen. Fürs Erste bin ich aber 
zufrieden. :)

Ich zeige dir an einem Bsp wie sich OO lohnt.
Hier ein Beispielprogramm, dass sich den Namen einer Person mit dem 
dazugehörigen Alter merken kann
Nicht OOrientiert brauch man 2 Arrays, jeder Person ist ein Index 
reserviert (Person 1 die 0, Person 2 die 1 usw) Siehe das Bsp:

1

String[] namen = new String[2]; //erzeugt ein Array mit Strings

2

int [] alter = new int[2]; //erzeuge ein Array mit int, das "alter" heißt

3

4

5

namen[0] = "Oliver";

6

alter[0] = 67;

7

8

namen[1] = Paul;

9

alter[1] =20;

10

11

namen[2] = Max;

12

alter[2]=33;

13

14

//gebe alle namen mit dem alter aus:

15

for ( int i = 0 ; i < 2; ++i){

16

System.out.println(alter[i] + " " + namen[i]);

17

}

Wenn man das nun OOrientiert macht, denkt man näher an der realität.
die Eigenschaften die eine Person hat (hier Name und alter) werden 
zunächst in einer Klasse festgelegt, danach werden die Personen an sich 
(hier sind es die Objekte) erzeugt. Man ist dann um die gleiche Funktion 
wie oben zu erhalt viel näher an der Realität weil man dann sagt: 
"Person, "geb dich aus...".. auch ist die Programmierung an sich 
einfacher weil  man nicht mit irgendwelchen Arrays arbeitet (stell dir 
vor es kommen noch 10 weitere Eigenschaften dazu, dann wird die Lösung 
von oben sehr schnell sehr unübersichtlich, die folgende OO orientierte 
bleibt jedoch klar verständlich)

1

class Person {

2

String name;

3

int alter;

4

5

public Person (String name, int alter){

6

this.name=name;

7

this.alter=alter;

8

}

9

public gebdichaus(){

10

System.out.println(name +  " "+  alter);

11

}

12

13

Hauptprogramm:

14

15

Person Oliver = new Person ("Oliver",67);

16

Person Paul = new Person("Paul",20);

17

Person Max = new Person("Max",33);

18

19

Oliver.gebdichaus();

20

Paul.gebdichaus();

21

Max.gebdichaus();

>>Nicht OOrientiert brauch man 2 Arrays....