Frage bezüglich Objektorientierter Programmierung

[C++ (Gast)]

Guten Morgen Zusammen

Vorab: Nein, es sind keine Hausaufgaben, auch wenn sich manch eine Frage 
vielleicht so anhört. Um den Vorwürfen die es hier sowiso oft gibt ein 
bisschen Entgegen zu wirken, habe ich unter jeder Frage bereits einmal 
meine Vermutung aufgeschrieben. Ich sitze gerade an meinem Arbeitsplatz 
(Berufslehre diesen Sommer abgeschlossen) und da ich nicht viel zutun 
habe, kann ich mir gerade ein paar Gedanken machen.

Wie dem Titel zu entnehmen ist, geht es mir um die Objektorientierte 
Programmierung. Nun, davon abgesehen dass ich das Prinzip noch nicht 
vollständig verstanden habe, trotzdem mal ein paar Fragen...

1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann 
auch in der uC Welt durchsetzen?

Vermutung: Eher weniger, da soweit ich das richtig verstanden habe die 
Objektorientierte Programmierung erst ab einem bestimmten Grad Sinn 
macht. Für die meisten Anwendungen genügt prozeduales vorgehen.

2. Wann lohnt sich Objektorientierte Programmierung?

Vermutung: Vor allem bei Anwendungen auf dem PC, bei denen viele Daten 
verschiedener Bereiche verarbeitet werden müssen.

3. Was für einen Vorteil bietet die O-O Programmierung gegenüber 
Prozedualer bei der Verarbeitung grosser Datenmengen?

Vermutung: Leider absolut keine Ahnung... Denke genau hier hackts dann 
bei mir. Dafür müsste ich wohl die O-O Programmierung verstehen bzw. den 
Sinn dahinter endlich einsehen. Im Internet gibt es leider nur sehr 
schlechte bzw. extrem komplizierte Erklärungen. Kaum etwas schlaues 
dabei, was den Sinn der O-O Progammierung gut erklärt.

4. Ist Objektorientierte Programmierung auch mit normalem C möglich?

Vermutung: Ja, allerdings nicht ganz in der Form wie es mit C++ möglich 
ist. Habe ich zumindest gelesen. Die genauen Unterschiede sind auf der 
Seite zwar beschrieben, allerdings verstehe ich diese nicht so ganz 
(liegt wohl auch wieder am fehlenden Verständniss von O-O 
Programmierung.)


Danke schon im vorraus bei jedem der sich hierfür Zeit nimmt.

[Falk B. (falk)]

@ C++ (Gast)

>1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann
>auch in der uC Welt durchsetzen?

Die uC Welt ist groß und vielschichtig. Da gibt es vom kleinsten 
8-Bitter bis zum ausgewachsenen 32 Bit Linux-Monster alles.

>Vermutung: Eher weniger, da soweit ich das richtig verstanden habe die
>Objektorientierte Programmierung erst ab einem bestimmten Grad Sinn
>macht. Für die meisten Anwendungen genügt prozeduales vorgehen.

Der Arduino nutzt ein (begrenztes) C++, und damit werden schon relativ 
kleine uCs programmiert. Wenn gleich das nicht immer super 
leistungsfähig ist, geht ein gewisser Trend schon dahin. Sobald man 
aktuelle, größere Frameworks la QT oder Embedded Windows etc. benutzt, 
muss man C++ programmieren. Wobei die Grenzen zwischen einem 
Mikrocontroller und einem kleinen Embedded PC fließend sind.

>2. Wann lohnt sich Objektorientierte Programmierung?

>Vermutung: Vor allem bei Anwendungen auf dem PC, bei denen viele Daten
>verschiedener Bereiche verarbeitet werden müssen.

Auch auf kleinen uCs können durchaus komplexe Programme laufen, die eine 
objektorientierte Programmierung notwendig bzw. sinnvoll machen.

>3. Was für einen Vorteil bietet die O-O Programmierung gegenüber
>Prozedualer bei der Verarbeitung grosser Datenmengen?

Höheres Abstraktionsniveau, daduch können größere Komplexitäten besser 
und einfacher gehandhabt werden. Der Compiler erledigt mehr 
Drecksarbeit.

>4. Ist Objektorientierte Programmierung auch mit normalem C möglich?

>Vermutung: Ja, allerdings nicht ganz in der Form wie es mit C++ möglich
>ist.

Genau.

[Smart resistor (Gast)]

C++ schrieb:
> 1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann
> auch in der uC Welt durchsetzen?

Nein, bei solchen primitiven Operationen wie bit in Byte-Register setzen 
hilft keine Datenkapselung oder Polymorphismus weiter. Das frisst mehr 
Speicherplatz und Rechenpower als ein uc bietet bzw. die Bateriie 
hergibt.

> 2. Wann lohnt sich Objektorientierte Programmierung?

Wenn man Programme erweitern möchte ohne sie neuzuschreiben.

> 4. Ist Objektorientierte Programmierung auch mit normalem C möglich?

Ja, die ersten Objektorientierten Implementierungen waren nix anders als 
makropakete die "normalen" C-Code erzeugten der den durch einen 
"normalen" C-Compilrer übersetzt wurde.

[Harald N. (haraldn)]

C++ schrieb:
> 1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann
> auch in der uC Welt durchsetzen?
Auf den ARMs machts denk ich schon Sinn von der Performance her
> 2. Wann lohnt sich Objektorientierte Programmierung?
Hängt vom Projekt ab
> 3. Was für einen Vorteil bietet die O-O Programmierung gegenüber
> Prozedualer bei der Verarbeitung grosser Datenmengen?
Kapselung, Wiederverwendung, Sicherheit, Abstrahierung
> 4. Ist Objektorientierte Programmierung auch mit normalem C möglich?
Nein.

Ausformulieren darfst du deine Prüfungsfragen selber ;-)

[C++ (Gast)]

Erst einmal vielen dank für die tollen Antworten bisher!

@Falk: Danke, top Antwort.

@Smart Resistor: Auch dir ein grosses Danke

@Harald: Auch dir ein danke, aber den letzten Satz hättest du dir sparen 
können. Wer lesen kann ist klar im Vorteil, die Begründung wieso ich 
diese Fragen stelle steht im Startpost. Ja, stellt euch vor, es gibt 
auch Leute die sich für sowas interessieren und das lernen wollen ohne 
dass eine Prüfung oder irgendeine Hausaufgabe dahintersteckt. ;) Mit 
meiner Ausbildung bin ich durch, allerdings nicht in diesem Bereich. Die 
Elektornik ist eher ein Hobby für mich und die O-O Programmierung ein 
Gebiet dass mich stark interessiert und ich mir nunmal Gedanken dazu 
mache. Trotzdem Danke ;)

[(prx) A. K. (prx)]

Objektorientierte Programmierung ist ein weites Feld.

Wenn man damit beispielsweise die Gesamtheit der C++/Java/... 
Mechanismen und Libraries meint, inklusive STL, etablierter höherer 
Programmschemata und mit entsprechenden Speicherwünschen, dann ist das 
eher nichts für einen Mega16, wird sich aber in Blackboxes mit Linux 
schon finden.

Dennoch kann man bestimmte Elemente objektorientierter 
Programmiersprachen auch auf einem Mega16 nutzen, wenn sie sich 
anbieten. Wenn eine Steuerung beispielsweise mehrere verschiedene Typen 
von Temperatursensoren hat, dann kann man deren Interface in C++ über 
Basisklasse und virtuelle Methoden elegant vereinheitlichen. Ebenso 
lassen sich Templates gezielt sinnvoll einsetzen, wenn man weiss was man 
tut.

[Karl H. (kbuchegg)]

C++ schrieb:

> 3. Was für einen Vorteil bietet die O-O Programmierung gegenüber
> Prozedualer bei der Verarbeitung grosser Datenmengen?
>
> Vermutung: Leider absolut keine Ahnung...

Du hast du einen Denkfehler.
OOP hat nichts mit Datenmengen zu tun.

OOP ist eine Methode um sein Programm zu organisieren. Welche 
Datenmengen dann durch das Programm durchgeschleust werden, spielt keine 
Rolle.

> bei mir. Dafür müsste ich wohl die O-O Programmierung verstehen bzw. den
> Sinn dahinter endlich einsehen.

Es ist 'nur' eine Art und Weise, wie man die Internals seines Programms 
auf die Reihe bringt und so strukturiert, dass eine einfache Pflege, 
Entwicklung und Weiterentwicklung des Programms möglich werden soll.

Das große Problem bei größeren Programmen besteht darin, dass man sehr 
leicht den Überblick verliert und sich (ungewollt) Querverflechtungen in 
den Code einbaut, die einen in weiterer Folge (durchaus auch Jahre 
später) bei einem Programmumbau bzw. bei Erweiterungen behindern. Dem 
kann man natürlich auch mit prozeduralen Mitteln, wie es sie in C gibt, 
entgegenwirken. Man ist aber immer auf die freiwillige Disziplin des 
Programmierers angewiesen.
OOP geht da einen Schritt weiter, in dem es Sprachmittel zur Verfügung 
stellt, mit der man auch von einem Rudel Programmierer zumindest eine 
gewisses Mindestquantum an Disziplin einfordern kann. OO ist in der 
Basis nichts anderes als das bewährte Prinzip des Information-Hidings.
Und das funktioniert grundsätzllich vom kleinen 8-Bit µC bis hinauf zum 
Supercomputer.
Auf einem µC, wie einem AVR wie er hier im Forum typischerweise benutzt 
wird, kann OOP seine eigentlichen Vorteile nicht so ganz ausspielen, 
weil der Umfang der Problemstellungen meist noch nicht so groß ist, so 
dass man das mit ganz kleinen Brötchen auch in zb. C noch gut und 
überschaubar hinkriegt, wenn man ein wenig Übung hat. Aber prinzipiell 
spricht nichts dagegen, wenn man auf ein paar der Killerfeatures von zb 
C++ verzichtet, die in der IMplementierung durch den Compiler recht 
'teuer' sind.

[Olaf (Gast)]

> 1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann
> auch in der uC Welt durchsetzen?

Zum Teil, es findet ja derzeit eine bemerkenswerte Inflation bei 
Rechenleistung uns Resourcen statt. Bei kleinen bis mittleren 
Stueckzahlen ist es heute kein Problem einen Prozessor zu verwenden mit 
dem sowas moeglich und sinnvoll ist.
Es gibt da aber zwei Probleme.

1. Bei kleinen Firmen ist der Hardwareentwickler oft auch der 
Softwareentwickler fuer die Firmware oder er haengt da zumindest mit 
drin. Solche Leute tun sich mit objektorientertem Denken schwer. Die 
wollen dann nicht. Auch wenn sie da natuerlich niemals zugeben wollen. 
:-)

2. Bei richtig grossen Stueckzahlen, ist es immer noch billiger eine 
moeglichst kleine Hardware einzusetzen.

> 2. Wann lohnt sich Objektorientierte Programmierung?

Wenn sehr viele Leute an einem Projekt arbeiten oder eine Software über 
viele Jahre von vielen Leuten immer wieder angefasst wird.

> 3. Was für einen Vorteil bietet die O-O Programmierung gegenüber
> Prozedualer bei der Verarbeitung grosser Datenmengen?

Das sehe ich keinen Vorteil. Eventuell ist die Geschwindigkeit in PlainC 
etwas hoeher wenn der Programmierer weiss was er tut.

> 4. Ist Objektorientierte Programmierung auch mit normalem C möglich?

Ja, viele der Ideen und Konzepte zu denen einen eine objektorientierte 
Sprache zwingt lassen sich in C freiwillig nutzen. Das ist der 
Unterschied zwischen einem guten C-Programmierer und einem Bastler.

Olaf

[C++ (Gast)]

Wow, das wird ja immer toller!

Karl Heinz schrieb:
> Du hast du einen Denkfehler.
> OOP hat nichts mit Datenmengen zu tun.
>
> OOP ist eine Methode um sein Programm zu organisieren. Welche
> Datenmengen dann durch das Programm durchgeschleust werden, spielt keine
> Rolle.

So meinte ich das eigentlich. Wollte damit sagen, OO Programmierung 
bringt bei grossen Datenmengen Vorteile im Bezug auf die Organisation, 
man hat mehr Überblick. Sehe ich das richtig?

Olaf schrieb:
> Ja, viele der Ideen und Konzepte zu denen einen eine objektorientierte
> Sprache zwingt lassen sich in C freiwillig nutzen. Das ist der
> Unterschied zwischen einem guten C-Programmierer und einem Bastler.

Das ist ein Teil der mich sehr stark interessiert. Auch wenn ich 
garantiert noch zu den "Bastlern" gehöre, versuche ich doch alles gut zu 
lernen. Mit C komme ich mittlerweile einigermassen gut zurecht, habe da 
auch schon einige coole Projekte zuhause realisiert und es macht mir 
einen riesigen Spass.

Objektorientiertes Programmieren interessiert mich vor allem weil ich 
nun vor habe ein Projekt zu erarbeiten, bei dem es gut möglich ist dass 
es in ein paar Jahren wieder erweitert wird, genau daher kommen die 
ganzen Fragen.


Hat vielleicht jemand einen Link um ein bisschen was über 
Objektorientiertes C zu lesen? Das hört sich sehr interessant an, vor 
allem weil man bei C nicht dazu gewzungen wird es zu verwenden. Ist da 
der Sinn dahinter ca. der selbe? Sprich, gibt dann auch Methoden und 
Klassen usw?

Gruss

[San L. (zwillingsfreunde)]

C++ schrieb:
> Hat vielleicht jemand einen Link um ein bisschen was über
> Objektorientiertes C zu lesen?

http://gefruckelt.de/programmieren/objektorientierung-in-ansi-c/

Für den Anfang. Denke, in das Thema einlesen wirst du dich wo anders 
müssen, vielleicht ein bisschen schwer zu verstehen. Trotzdem schonmal 
ein komplettes Beispiel inklusive Code & Beschreibung.

[Karl H. (kbuchegg)]

C++ schrieb:

> Hat vielleicht jemand einen Link um ein bisschen was über
> Objektorientiertes C zu lesen?

In dem Moment, in dem du deine Funktionen samt Daten eines Moduls in 
einem Header File bzw. Source Code File so organisierst, dass ein 
Verwender dieses Moduls nur noch über die Funktionsschnittstelle mit dem 
Modul arbeitet und nichts meh über die Interna des Moduls wissen muss 
bzw. wissen kann, arbeitest du bereits objektorientiert.
Denn genau das ist die Grundidee der OOP:
Daten und die Funktionen die auf den Daten arbeiten, sind eine Einheit, 
die sich nach aussen hin abschotten. Wenn jemand anderer etwas von 
diesem Modul will, dann hat er gefälligst über diese Schnittstellen zu 
gehen.

> Das hört sich sehr interessant an, vor
> allem weil man bei C nicht dazu gewzungen wird es zu verwenden. Ist da
> der Sinn dahinter ca. der selbe? Sprich, gibt dann auch Methoden und
> Klassen usw?

Nein.
Es gibt ganz normal weiterhin Strukturen.

Nehmen wir einen Stack. Du schreibst den zb so

int StackPtr;
int Stack[20];

void Init()
{
  StackPtr = 0;
}

void Push( int i )
{
  Stack[StackPtr++] = i;
}

int Pop()
{
  return Stack[--StackPtr];
}  

int main()
{
  Init();

  Push( 5 );
  printf( "%d\n", Pop() );
}

daran gibt es erst mal nichts auszusetzen. Ist ganz normales C

Jetzt hast du aber erkannt, dass ein Stack etwas ist, das du an mehreren 
Stellen brauchen würdest. Also lagerst du die Funktionen in ein Header 
File und ein C File aus.

Stack.h

void Init();
void Push( int i );
int Pop();

Stack.c

#include "stack.h"

static int StackPtr;
static int Stack[20];

void Init()
{
  StackPtr = 0;
}

void Push( int i )
{
  Stack[StackPtr++] = i;
}

int Pop()
{
  return Stack[--StackPtr];
}

#include "stack.h"

int main()
{
  Init();

  Push( 5 );
  printf( "%d\n", Pop() );
}

Jetzt kommst du aber drauf, dass du mehrere Stacks auf einmal brauchen 
würdest. Da ist es nicht so prickelnd, dass du nur einen Satz Variablen 
für den Stack zur Verfügung hast. ALso gehst du her und machst dir eine 
Struktur, in der du die beiden Variablen zu einer Einheit zusammenfasst

Stack.h

struct stack_t
{
  int StackPtr;
  int Stack[20];
};

void Init( struct stack_t* this );
void Push( struct stack_t* this, int i );
int Pop( struct stack_t* this);

Stack.c

#include "stack.h"

void Init( struct stack_t* this )
{
  this->StackPtr = 0;
}

void Push( struct stack_t* this, int i )
{
  this->Stack[ (this->StackPtr)++ ] = i;
}

int Pop( struct stack_t* this )
{
  return this->Stack[ --(this->StackPtr)];
}

#include "stack.h"

int main()
{
  struct stack_t stack_A;
  struct stack_t stack_B;

  Init( &stack_A );
  Init( &stack_B );

  Push( &stack_A, 5 );
  Push( &stack_B, 8 );

  printf( "%d\n", Pop( &stack_B ) );
  printf( "%d\n", Pop( &stack_A ) );
}

Der Preis dafür ist, dass du jeder Funktion jetzt natürlich mitgeben 
musst, auf welchem Stack sie eigentlich operiert. Aber du kriegst dafür 
die Fähigkeit, dass dieselben Funktionen mit verschiedenen 
Struktur-'Objekten' arbeiten können. Die Objekte enthalten alle Daten 
und die Funktionen können mit diesen Daten umgehen.

Ein weiterer Schritt in Richtung OOP wurde gemacht.
C++ stülpt da jetzt noch eine weitere Dimension drüber, denn im Prinzip 
hindert dich ja bisher nichts und niemand daran, in main das hier zu tun

 int main()
{
  struct stack_t stack_A;
  struct stack_t stack_B;

  Init( &stack_A );
  Init( &stack_B );

  stack_B.StackPtr = 28;   // <-----------------------

  Push( &stack_A, 5 );
  Push( &stack_B, 8 );

  printf( "%d\n", Pop( &stack_B ) );
  printf( "%d\n", Pop( &stack_A ) );
}

... mit entsprechend verheerenden Auswirkungen auf die 
Funktionsfähigkeit dieser 'Stack' Objekte. Die Struktur hat keine 
Möglichkeit sich davor zu schützen.
Aber in C++ kann sie genau das.

stack.h

class stack_t
{
  public:
    stack_t();     // KOnstruktor. Ersetzt die Init Funktion

    void Push( int i );
    int  Pop();

  private:
    int StackPtr;
    int Stack[20];
};

stack.cpp

#include "stack.h"

void stack_t::stack_t()
{
  this->StackPtr = 0;
}

void stack_t::Push( int i )
{
  this->Stack[ (this->StackPtr)++ ] = i;
}

int stack_t::Pop()
{
  return this->Stack[ --(this->StackPtr)];
}

Das Konglomerat aus Daten und Funktionen wurde noch enger verwoben. Die 
Funktionen sind jetzt integraler Bestandteil des Datentyps "stack_t". 
Sie gehören genauso dazu, wie es auch die Daten sind. Zusätzlich kann 
ich die Daten schützen. Dadurch, dass ich die beiden Variablen 'private' 
gemacht habe, ist es nicht mehr möglich von ausserhalb einer der 
Funktionen die zu dieser Klasse gehören auf sie einfach so zuzugreifen.
Da die Funktionen integraler Bestandteil der Klasse sind, benötige ich 
dann auch ein entsprechendes Objekt um die Funktionen aufzurufen, die 
dann auf diesem Objekt operieren. Das unterscheidet sich nicht wirklich 
wesentlich vom Schritt vorher, bei dem ich jeder Funktion einen Pointer 
auf ein entsprechendes Struktur Objekt mitgeben musste. Man könnte 
sagen: die Syntax ist ein bischen anders, aber das Prinzip ist 
eigentlich so ziemlich dasselbe

#include "stack.h"

int main()
{
  stack_t stack_A;   // 'Init' brauch ich nicht Aufrufen. Konstruktoren
  stack_t stack_B;   // werden automatisch beim Erzeugen eines Objektes
                     /7 aufgerufen

  stack_A.Push( 5 );
  stack_B.Push( 8 );

  printf( "%d\n", stack_B.Pop() );
  printf( "%d\n", stack_A.Pop() );
}

so viel hat sich also gar nicht geändert. Allerdings ein

  stack_A.StackPtr = 28;

kann ich schon nicht mehr machen. StackPtr ist private in der Klasse und 
von daher von hier aus nicht ansprechbar. Funktionen, die Mitglied der 
Klasse sind, kommen an die Variable ran. Funktionen die nicht Mitglied 
sind, kommen nicht ran.
Die Init Funktion ist einem Konstruktor gewichen. Der Vorteil ist, dass 
ich nicht vergessen kann, diese Funktion aufzurufen. Denn sobald ich ein 
derartiges Objekt erzeuge, wird die Konstruktor Funktion immer 
aufgerufen. In C kann ich den Aufruf irrtümlich vergessen. In C++ nicht.

Das was du in C noch per 'freilliger Selbstbeschränkung' gemacht hast, 
nämlich nicht von ausserhalb der Stack Funktionen an den Stack Variablen 
rumzufummeln, das kannst du in C++ als OOP Sprache einfordern.


Anmerken möchte ich noch, das das erst der Anfang von OOP ist. Ab hier 
fangen dann noch viele weitere Konzepte an.

[Jan S. (jevermeister)]

Objektorientierte Programmierung ist ein Hilfsmittel und keine 
allgemeine Lösung für Probleme. Ich habe schon ganz fiese Konstrukte in 
C++ im hardwarenahen Embedded-Bereich gesehen, die man in C sehr viel 
übersichtlicher und einfacher hätte können. Umgekehrt gibt es auch sehr 
viel Pseudo-C++ von ehemaligen C-Programmierern für GUIs etc, wo im 
Endeffekt auch direkt C hätte schreiben können.

[C++ (Gast)]

@Karl Heinz: Wow... vielen vielen dank für die tolle Erklärung!!! Ich 
verstehe davon zwar nur rund 1/3, aber dank dir habe ich nun eine 
Referenz. Werde mir das nun imme rund immer wieder durchlesen und alles 
was ich nicht verstehe, frage ich den lieben Herrn Google.

Danke!!!

[Gustav (Gast)]

Karl Heinz schrieb:
> Denn genau das ist die Grundidee der OOP:
> Daten und die Funktionen die auf den Daten arbeiten, sind eine Einheit,

Schonmal CLOS gesehen?

[Axel S. (a-za-z0-9)]

C++ schrieb:

> Wie dem Titel zu entnehmen ist, geht es mir um die Objektorientierte
> Programmierung. Nun, davon abgesehen dass ich das Prinzip noch nicht
> vollständig verstanden habe, trotzdem mal ein paar Fragen...

Der Begriff "OOP" ist sehr überladen und wird auch nicht einheitlich 
verwendet. Frage 10 Leute, was OOP ist und du wirst 11 Meinungen hören.

Typische Techniken der OOP sind:

- strenge(re) Kapselung der Daten (private/public/friend Konzept)
- Bündelung von Daten und Operationen auf diesen Daten (Methoden) zu 
Objekten (Typen)
- Vererbung (Objekthierarchien)
- Polymorphie auf Objektebene (ein Objekt wird nicht unter seinem 
"eigentlichen" Typ, sondern als einer der Basistypen verwendet)
- Funktions/Operatorüberladung (mehrere Funktionen mit gleichem Namen 
aber unterschiedlichen Parametern, Operatoren für eigene Typen)
- generische Programmierung (z.B. C++ Templates)
- Exception-Handling (try/catch/throw)

u.v.m.

IMHO wird (wurde?) OOP seinerzeit viel zu sehr gehyped. Es gibt sicher 
Programme, die von der Anwendung von OOP-Techniken profitieren; z.B. 
dahingehend daß der Programmcode lesbarer wird. Allerdings habe ich auch 
schon oft das Gegenteil gesehen. Aus diesem Grund lehne ich "strenge" OO 
Sprachen, die gar keine prozeduralen Elemente mehr erlauben, auch ab. 
Klassisches Negativbeispiel ist Java, das nicht mal mehr eine main() 
Funktion erlaubt und den (IMHO gräßlichen) Workaround erfordert, main() 
als statische Methode einer Dummyklasse zu definieren.


> 1. Denkt ihr, die Objektorientierte Programmierung wird sich irgendwann
> auch in der uC Welt durchsetzen?

Hat sie schon. Wobei "µC Welt" ein natürlich weites Feld ist.

> 2. Wann lohnt sich Objektorientierte Programmierung?

Sobald man Vorteile aus einem der Paradigmen ziehen kann, die unter dem 
Begriff "OOP" zusammengefaßt werden.

Am deutlichsten wird das IMHNSHO bei neuen numerischen Typen. Z.B. ein 
Programm das mit komplexen zahlen rechnen muß. Ohne OO muß man dann mit 
zwei z.B. double Variablen für Real- und Imaginärteil herumhampeln und 
wenn man Operationen (z.B. die Multiplikation zweier komplexer Zahlen) 
in Funktionen kapselt, dann hat man das Problem daß längere Ausdrücke 
total unlesbar sind.

Unter Verwendung eines (sebstdefinierten oder aus einer Library 
stammenden) Typs complex wird der Programmcode sehr viel lesbarer, 
weil man bspw. sowas schreiben kann:

complex c1, c2, c2, c4, c5;
...
c1= (c2+c3)*(c4+c5);

um die Verwaltung der entstehenden Zwischenergebnisse kümmert sich dann 
der Compiler.

Statt komplexer Zahlen kann man genausogut Bignums (für Crypto) oder 
Matrizen (3D-Transformationen z.B. für Quadcopter) betrachten.

> 3. Was für einen Vorteil bietet die O-O Programmierung gegenüber
> Prozedualer bei der Verarbeitung grosser Datenmengen?

Die Frage ist falsch gestellt. OOP bietet Vorteile beim Schreiben des 
Programmcodes. Die Daten die das Programm nachher verarbeitet, 
interessiert nicht die Bohne ob das Programm mit OOP Techniken 
geschrieben wurde oder nicht. Auch die Geschwindigkeit des vom Compiler 
erzeugten Maschinencodes ist (im Optimalfall) nicht davon abhängig ob 
das Programm OOP verwendet oder nicht. Ein gängiges Vorurteil besagt, 
daß OOP zu langsameren Programmen führt. Das würde ich so generell nicht 
unterschreiben.

> 4. Ist Objektorientierte Programmierung auch mit normalem C möglich?

Im Prinzip ja. Es gibt sogar Leute, die propagieren OOP in Assembler. 
Halte ich nicht für zielführend. Eine Grundidee bei OOP ist, den 
Programmcode leichter lesbar/wartbar zu machen. Das erzwingt IMHO auch 
neue Sprachfeatures.


XL

[Karl H. (kbuchegg)]

Gustav schrieb:
> Karl Heinz schrieb:
>> Denn genau das ist die Grundidee der OOP:
>> Daten und die Funktionen die auf den Daten arbeiten, sind eine Einheit,
>
> Schonmal CLOS gesehen?

Lass uns jetzt bitte für den TO die Sache nicht noch komplizierter 
machen. In Lisp ist alles irgendwie anders.

[Harald N. (haraldn)]

Karl Heinz schrieb:
> In dem Moment, in dem du deine Funktionen samt Daten eines Moduls in
> einem Header File bzw. Source Code File so organisierst, dass ein
> Verwender dieses Moduls nur noch über die Funktionsschnittstelle mit dem
> Modul arbeitet und nichts meh über die Interna des Moduls wissen muss
> bzw. wissen kann, arbeitest du bereits objektorientiert.
> Denn genau das ist die Grundidee der OOP:
> Daten und die Funktionen die auf den Daten arbeiten, sind eine Einheit,
> die sich nach aussen hin abschotten. Wenn jemand anderer etwas von
> diesem Modul will, dann hat er gefälligst über diese Schnittstellen zu
> gehen.

Das stimmt bestimmt ein Stück weit. Allerdings kommt es darauf an, wie 
eng man die Definition von OO sieht...
IMHO kann man in C zwar OOP implementieren. Wenn man dies allerdings 
anständig macht, landet man früher oder später bei seiner eigenen 
C++-Implementation - zumindest was die OOP-Geschichten betrifft.
Und es gibt ja noch einige Sprachen mehr, die die OO wahrlich zum 
obersten Prinzip erklären... Denkt mal an Smalltalk, Eiffel oder Java.

[albert darbooven (Gast)]

Harald Nagy schrieb:
> IMHO kann man in C zwar OOP implementieren. Wenn man dies allerdings
Typsicherheit bekommt man damit nicht hin, ok in dem Schrott C++ auch 
nicht wenn man es darauf ankommen lässt, C++ ist sowieso völlig kaputt 
designed  Und um sowas wie Polymorphie in C nachzubauen sind auch elende 
Verrenkungen nötig, das kann man aber alles wieder umgehen und genau das 
will man in einer echten OO-Sprache nicht. Da nimmt man gleich ein 
Sprache die OO-Konzepte von Haus aus mitbringt.

In der Praxis spielt das alles viel weniger eine Rolle als man es in der 
Theorie lernt, da nimmt man dann doch wieder das kaputte C++, oder Java 
mit seinen kaputten Generics, oder den Scherzartikel PHP, ... andere 
Dinge sind eben auch wichtig, sogar wichtiger als ein sauberes OO-System 
nach der reinen Lehre.

Wichtig st dass man die Konzept kapiert hat, das nutzt einem auch in 
einer Nicht-OOP-Sprache seinen Code OO-mässig aufzubauen und damit 
besser zu handeln, wenn man es nicht übertreibt (In C OO-Features 
nachzubauen).

[Harald N. (haraldn)]

So formuliert bin ich ganz bei dir.

[Purzel H. (hacky)]

Objektorientierte Programmierung ist ein Konzept. Daraus kann man 
uebernehmen was man will. Ob man mit C++ arbeitet oder auch nicht.

Es beinhaltet
-Kapselung, dh Code und Daten die zusammengehoeren zusammen 
definieren/deklarieren
-Vererbung, dh erweitern bestehender Funktionalitaet in Daten und Code
-Virtualisierung, wenn man die Hardware austauschen koennen will.

Es braucht nicht zwingend dynamischen Speicher. Den mag ich zB auch 
nicht.

[Harald N. (haraldn)]

Siebzehn Zu Fuenfzehn schrieb:
> Es braucht nicht zwingend dynamischen Speicher. Den mag ich zB auch
> nicht.

Wo genau wurde behauptet, dass dies Teil von OOP ist? Kann sein, dass 
ich es überlesen habe...