Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
basiskonzepte [2019/01/29 15:33]
127.0.0.1 Externe Bearbeitung
basiskonzepte [2019/07/27 16:35] (aktuell)
huwi
Zeile 1: Zeile 1:
->>>​**„Nichts ist schwieriger als das Vereinfachen. Nichts ist einfacher als das Komplizieren.“** +>​**„Nichts ist schwieriger als das Vereinfachen. Nichts ist einfacher als das Komplizieren.“** 
->>><​sup>​Georges Elgozy ( Politiker und Autor, 1909-1989)</​sup>​+><​sup>​Georges Elgozy ( Politiker und Autor, 1909-1989)</​sup>​
  
 ====== Basiskonzepte ====== ====== Basiskonzepte ======
Zeile 19: Zeile 19:
 Das Gegenständliche bilden wir in Begriffen ab. Und mehr soll an dieser Stelle dazu auch nicht gesagt werden. ​ Das Gegenständliche bilden wir in Begriffen ab. Und mehr soll an dieser Stelle dazu auch nicht gesagt werden. ​
  
->>>**Wir geben den Dingen Namen**. ​+>**Wir geben den Dingen Namen**. ​
  
->>>​{{:​taster.jpg?​200|}}+>​{{:​taster.jpg?​200|}}
  
 ===== Objekt ===== ===== Objekt =====
 Womit wir beim nächsten Punkt sind. Dinge bezeichnet der Fachmann als Objekte und mal ehrlich, //​Dingorientierung//​ klingt auch nicht wirklich sexy. Also dann doch lieber Objektorientierung. Objekte, das sind die Bausteine, aus denen die Systeme welche wir programmieren wollen bestehen. Für uns sind das zum Beispiel der AVR-**Controller**,​ vielleicht ein **Taster** und eine **LED** usw.. Diese Objekte besitzen konkrete Eigenschaften und typisches Verhalten. Der Controller hat eine bestimmte Speicherkapazität,​ der Taster prellt etwas und die LED leuchtet grün. Die Eigenschaften bilden wir in Programmen als Variablen (Attribute) und das Verhalten als Funktionen (auch Methoden bzw. Operationen genannt) ab. Programmieren wir objektorientiert,​ müssen wir dafür sorgen, dass auch das Programm aus genau diesen Objekten besteht und die Attribute und Operationen diesen Objekten zugeordnet sind. Womit wir beim nächsten Punkt sind. Dinge bezeichnet der Fachmann als Objekte und mal ehrlich, //​Dingorientierung//​ klingt auch nicht wirklich sexy. Also dann doch lieber Objektorientierung. Objekte, das sind die Bausteine, aus denen die Systeme welche wir programmieren wollen bestehen. Für uns sind das zum Beispiel der AVR-**Controller**,​ vielleicht ein **Taster** und eine **LED** usw.. Diese Objekte besitzen konkrete Eigenschaften und typisches Verhalten. Der Controller hat eine bestimmte Speicherkapazität,​ der Taster prellt etwas und die LED leuchtet grün. Die Eigenschaften bilden wir in Programmen als Variablen (Attribute) und das Verhalten als Funktionen (auch Methoden bzw. Operationen genannt) ab. Programmieren wir objektorientiert,​ müssen wir dafür sorgen, dass auch das Programm aus genau diesen Objekten besteht und die Attribute und Operationen diesen Objekten zugeordnet sind.
  
->>>**Die Bausteine, aus denen das System besteht sind der Ausgangspunkt der Softwareentwicklung. Diese Bausteine bezeichnen wir als Objekte.**+>**Die Bausteine, aus denen das System besteht sind der Ausgangspunkt der Softwareentwicklung. Diese Bausteine bezeichnen wir als Objekte.**
  
->>>​{{:​taster_objekt.jpg?​350|}}+>​{{:​taster_objekt.jpg?​350|}}
  
 ===== Klasse ===== ===== Klasse =====
 Der Name welchen wir für ein Ding benutzen bezeichnet meist nicht nur das einzelne Ding, sondern eine Menge (Gruppe) gleichartiger Dinge. Nehmen wir zum Beispiel den **Taster**. Davon haben wir auf unserem Experimentierboard schon mal zwei Stück. Um diese zu unterscheiden,​ geben wir jedem noch einen individuellen Namen nämlich **Taster-1** und **Taster-2**. Taster steht also als Begriff für alle Schalter mit den entsprechenden gleichen Eigenschaften. Der Fachmann bezeichnet so etwas als Kategorie oder auch als Klasse. Die beiden Objekte Taster-1 und Taster-2 sind Bausteine unseres Systems und gehören zur Klasse (Gruppe) der Taster. Unser oberschlauer Fachmann bezeichnet diese beiden konkreten Objekte auch gern als Instanzen der Klasse Taster. Übrigens kennen wir diese Problematik schon aus der klassischen Programmierung in Form von Typen und Variablen. Klassen sind die Typen und die Objekte so etwas wie die Variablen. Der Name welchen wir für ein Ding benutzen bezeichnet meist nicht nur das einzelne Ding, sondern eine Menge (Gruppe) gleichartiger Dinge. Nehmen wir zum Beispiel den **Taster**. Davon haben wir auf unserem Experimentierboard schon mal zwei Stück. Um diese zu unterscheiden,​ geben wir jedem noch einen individuellen Namen nämlich **Taster-1** und **Taster-2**. Taster steht also als Begriff für alle Schalter mit den entsprechenden gleichen Eigenschaften. Der Fachmann bezeichnet so etwas als Kategorie oder auch als Klasse. Die beiden Objekte Taster-1 und Taster-2 sind Bausteine unseres Systems und gehören zur Klasse (Gruppe) der Taster. Unser oberschlauer Fachmann bezeichnet diese beiden konkreten Objekte auch gern als Instanzen der Klasse Taster. Übrigens kennen wir diese Problematik schon aus der klassischen Programmierung in Form von Typen und Variablen. Klassen sind die Typen und die Objekte so etwas wie die Variablen.
  
->>>**Wir geben einer Menge gleichartiger Bausteinen einen Gruppennamen (Klassennamen) und beschreiben die gemeinsamen Merkmale (Attribute und Operationen). Objekte sind Instanzen einer Klasse.**+>**Wir geben einer Menge gleichartiger Bausteinen einen Gruppennamen (Klassennamen) und beschreiben die gemeinsamen Merkmale (Attribute und Operationen). Objekte sind Instanzen einer Klasse.**
  
->>>​{{:​taster_klasse.jpg?​700|}}+>​{{:​taster_klasse.jpg?​700|}}
  
 ===== Vererbung ===== ===== Vererbung =====
 Taster haben mit DIP-Schaltern und Bausteinen der [[http://​de.wikipedia.org/​wiki/​74xx|74er Reihe]] etwas gemeinsam, sie liefern digitale Signale. Wesentliche Aspekte der Programmierung für Ein- und Ausgaben sind bei all diesen Bausteinen gleich. In der objektorientierten Systementwicklung ist man bestrebt, gemeinsame Merkmale (Attribute und Operationen) nur einmal zu programmieren,​ um Arbeitsaufwand zu sparen. Das einmal programmierte Merkmal soll aber in allen Bausteinen wiederverwendet werden. Dazu benutzt man den Mechanismus der Vererbung. Das bedeutet, man muss eine allgemeingültige Basisklasse schaffen und dort die gemeinsamen Merkmale programmieren. Das könnte für die oben genannten Bausteine zum Beispiel die Klasse //​Digital_Baustein//​ sein. Das man für einen Taster noch einen [[http://​www.rn-wissen.de/​index.php/​Pullup|PullUp]] benötigt ist etwas Spezielles und gehört nicht zu den gemeinsamen Merkmalen. Ein solches spezielles Merkmal wird dann auch nicht in der Basisklasse //​Digital_Baustein//​ sondern in einer speziellen Klasse, die zum Beispiel eben genau //Taster// oder wer es denglisch mag, //​PushButton//​ heißen könnte programmiert,​ aber die Masse an Merkmalen erbt der Taster von seiner Basisklasse. Diese spezialisierten Klassen nennt der Fachmann auch Ableitungen. Umgangssprachlich lässt sich Vererbung mit **"ist ein/ist eine"​** ausdrücken. Taster haben mit DIP-Schaltern und Bausteinen der [[http://​de.wikipedia.org/​wiki/​74xx|74er Reihe]] etwas gemeinsam, sie liefern digitale Signale. Wesentliche Aspekte der Programmierung für Ein- und Ausgaben sind bei all diesen Bausteinen gleich. In der objektorientierten Systementwicklung ist man bestrebt, gemeinsame Merkmale (Attribute und Operationen) nur einmal zu programmieren,​ um Arbeitsaufwand zu sparen. Das einmal programmierte Merkmal soll aber in allen Bausteinen wiederverwendet werden. Dazu benutzt man den Mechanismus der Vererbung. Das bedeutet, man muss eine allgemeingültige Basisklasse schaffen und dort die gemeinsamen Merkmale programmieren. Das könnte für die oben genannten Bausteine zum Beispiel die Klasse //​Digital_Baustein//​ sein. Das man für einen Taster noch einen [[http://​www.rn-wissen.de/​index.php/​Pullup|PullUp]] benötigt ist etwas Spezielles und gehört nicht zu den gemeinsamen Merkmalen. Ein solches spezielles Merkmal wird dann auch nicht in der Basisklasse //​Digital_Baustein//​ sondern in einer speziellen Klasse, die zum Beispiel eben genau //Taster// oder wer es denglisch mag, //​PushButton//​ heißen könnte programmiert,​ aber die Masse an Merkmalen erbt der Taster von seiner Basisklasse. Diese spezialisierten Klassen nennt der Fachmann auch Ableitungen. Umgangssprachlich lässt sich Vererbung mit **"ist ein/ist eine"​** ausdrücken.
  
->>>​**Basisklassen sind oft schon vorhanden und enthalten häufig benötigte Merkmale. Diese zu benutzen (von diesen zu erben) spart Programmieraufwand.**+>​**Basisklassen sind oft schon vorhanden und enthalten häufig benötigte Merkmale. Diese zu benutzen (von diesen zu erben) spart Programmieraufwand.**
  
->>>​{{:​vererbung.jpg?​500|}}+>​{{:​vererbung.jpg?​500|}}
  
 ===== Kapselung (Sichtbarkeit) ===== ===== Kapselung (Sichtbarkeit) =====
 Besonders dann, wenn der Benutzer einer Klasse nicht deren Entwickler ist kann es wichtig sein, bestimmte interne Sachverhalte der Klasse vor versehentlich falscher Benutzung zu schützen. Dafür kennt die Objektorientierung das Konzept der Sichtbarkeit. Attributen und Operationen können zum Schutz vor unsachgemäßem Zugriff unterschiedliche Sichtbarkeiten zugewiesen werden. Man unterscheidet in der Theorie zwischen den Sichtbarkeiten:​ public, package, protected und privat. Für den Anfang wollen wir erst einmal nur die Sichtbarkeiten **public** und **protected** unterscheiden. Wie deren Namen bereits verdeutlichen,​ heißt public (öffentlich),​ dass von außen zugegriffen werden darf und protected (geschützt),​ dass der Zugriff nicht erlaubt ist. Besonders dann, wenn der Benutzer einer Klasse nicht deren Entwickler ist kann es wichtig sein, bestimmte interne Sachverhalte der Klasse vor versehentlich falscher Benutzung zu schützen. Dafür kennt die Objektorientierung das Konzept der Sichtbarkeit. Attributen und Operationen können zum Schutz vor unsachgemäßem Zugriff unterschiedliche Sichtbarkeiten zugewiesen werden. Man unterscheidet in der Theorie zwischen den Sichtbarkeiten:​ public, package, protected und privat. Für den Anfang wollen wir erst einmal nur die Sichtbarkeiten **public** und **protected** unterscheiden. Wie deren Namen bereits verdeutlichen,​ heißt public (öffentlich),​ dass von außen zugegriffen werden darf und protected (geschützt),​ dass der Zugriff nicht erlaubt ist.
  
->>>​**Objekte können zum Schutz bestimmte Merkmale (vor allem Eigenschaften aber auch Verhalten) verbergen.**+>​**Objekte können zum Schutz bestimmte Merkmale (vor allem Eigenschaften aber auch Verhalten) verbergen.**
  
  
Zeile 53: Zeile 53:
 Das Konzept der Nachrichten müssen wir aus zwei Blickwinkeln betrachten. Zum einen im Zusammenhang mit der oben genannten Kapselung. Es hat sich bewährt vor allem Attribute vor dem direkten Zugriff zu schützen und das Schreiben oder Lesen von Attributen nur über den Aufruf von Operationen zu ermöglichen. Dieser Aufruf von Operationen bedeutet, dem betreffenden Objekt eine Nachricht zu senden. Das Objekt kann auf die Nachricht antworten, diese Antwort ist dann der Rückgabewert der Operation. Somit kommuniziert also das System mit seinen Bausteinen über diese Nachrichten. Das der Aufruf von Operationen Nachricht und nicht Befehle genannt wird (obwohl er aussieht wie der Befehl in einer klassischen Programmiersprache) soll ausdrücken,​ dass der Empfänger entscheidet,​ was auf die Nachricht hin getan wird. So kann es durchaus sein, dass das System dem Objekt //​Seitenfenster_links//​ zwar die Nachricht //​schließen//​ sendet, dieses aber nicht darauf reagiert. Solch ein Verhalten muss kein Programmierfehler sein. Das Objekt //​Seitenfenster_links//​ könnte zum Beispiel über die Messung des Motorstroms eine Blockade festgestellt haben und entscheidet für sich selbst zur Sicherheit den Motor abzuschalten,​ ohne erst mal um Genehmigung zu bitten. Das Konzept der Nachrichten müssen wir aus zwei Blickwinkeln betrachten. Zum einen im Zusammenhang mit der oben genannten Kapselung. Es hat sich bewährt vor allem Attribute vor dem direkten Zugriff zu schützen und das Schreiben oder Lesen von Attributen nur über den Aufruf von Operationen zu ermöglichen. Dieser Aufruf von Operationen bedeutet, dem betreffenden Objekt eine Nachricht zu senden. Das Objekt kann auf die Nachricht antworten, diese Antwort ist dann der Rückgabewert der Operation. Somit kommuniziert also das System mit seinen Bausteinen über diese Nachrichten. Das der Aufruf von Operationen Nachricht und nicht Befehle genannt wird (obwohl er aussieht wie der Befehl in einer klassischen Programmiersprache) soll ausdrücken,​ dass der Empfänger entscheidet,​ was auf die Nachricht hin getan wird. So kann es durchaus sein, dass das System dem Objekt //​Seitenfenster_links//​ zwar die Nachricht //​schließen//​ sendet, dieses aber nicht darauf reagiert. Solch ein Verhalten muss kein Programmierfehler sein. Das Objekt //​Seitenfenster_links//​ könnte zum Beispiel über die Messung des Motorstroms eine Blockade festgestellt haben und entscheidet für sich selbst zur Sicherheit den Motor abzuschalten,​ ohne erst mal um Genehmigung zu bitten.
  
->>>**Das System arbeiten mit seinen Bausteinen zusammen, indem es mit diesen Nachrichten austauscht.**+>**Das System arbeiten mit seinen Bausteinen zusammen, indem es mit diesen Nachrichten austauscht.**
  
 {{:​nachricht.jpg?​400|}} {{:​nachricht.jpg?​400|}}
Zeile 60: Zeile 60:
 Um Komplexität zu beherrschen kann man größere Dinge aus kleineren zusammenbauen. Dabei ist das Ganze **verantwortlich** für seine Einzelteile. Das ist nicht nur beim Programmieren so. Es verwundert also nicht, dass in einer obejektorientierten Programmiersprache komplexe Klassen aus einfachen zusammengebaut werden können. Die **Verantwortlichkeit** kann man vereinfacht mit **"​hat"​** ausdrücken. Um Komplexität zu beherrschen kann man größere Dinge aus kleineren zusammenbauen. Dabei ist das Ganze **verantwortlich** für seine Einzelteile. Das ist nicht nur beim Programmieren so. Es verwundert also nicht, dass in einer obejektorientierten Programmiersprache komplexe Klassen aus einfachen zusammengebaut werden können. Die **Verantwortlichkeit** kann man vereinfacht mit **"​hat"​** ausdrücken.
  
->>>​**Komplexe Systeme bestehen aus einfachen Bausteinen.**+>​**Komplexe Systeme bestehen aus einfachen Bausteinen.**
  
->>>​{{:​aggregation.jpg?​500|}}+>​{{:​aggregation.jpg?​500|}}
  
 ===== Assoziation ===== ===== Assoziation =====
 Manchmal ist es erforderlich,​ dass Einzelteile direkt miteinander Nachrichten austauschen. Der kleine Dienstweg sozusagen. Dabei besteht als wesentlicher Unterschied zur Aggregation,​ dass die Einzelteile nicht füreinander verantwortlich sind, sich aber **"​kennen"​**. ​ Manchmal ist es erforderlich,​ dass Einzelteile direkt miteinander Nachrichten austauschen. Der kleine Dienstweg sozusagen. Dabei besteht als wesentlicher Unterschied zur Aggregation,​ dass die Einzelteile nicht füreinander verantwortlich sind, sich aber **"​kennen"​**. ​
  
->>>​**Bausteine können mit anderen Bausteinen in Beziehung stehen. Man kennt sich.**+>​**Bausteine können mit anderen Bausteinen in Beziehung stehen. Man kennt sich.**
  
 {{:​aggr_asso.jpg?​500|}} {{:​aggr_asso.jpg?​500|}}
Zeile 73: Zeile 73:
 ===== Lange Rede kurzer Sinn ===== ===== Lange Rede kurzer Sinn =====
  
->>>​**Unsere natürliche Sprache ist objektorientiert!**+>​**Unsere natürliche Sprache ist objektorientiert!**
  
->>><​code>​+><​code>​
 Wenn der Taster gedrückt ist schalte die LED an. Wenn der Taster gedrückt ist schalte die LED an.
 If the button is pressed the LED will turn on. If the button is pressed the LED will turn on.
Zeile 83: Zeile 83:
  
  
-Mit Herrn Andreas Willert von [[http://​www.willert.de/​|Willert Software Tools]] habe ich die soeben dargestellte Problematik in einem seiner Newsletter noch etwas verfeinert. Diesen Beitrag finden Sie hier: [[http://​www.willert.de/​assets/Newsletter/ESER30-OOP-V1.1.pdf|Embedded Software Engineering Report Nr. 30]].+Mit Herrn Andreas Willert von [[http://​www.willert.de/​|Willert Software Tools]] habe ich die soeben dargestellte Problematik in einem seiner Newsletter noch etwas verfeinert. Diesen Beitrag finden Sie hier: [[https://​www.willert.de/​docs/pdf/Willert-Embedded-Software-Engineering-Report30%20-%20OOP.pdf|Embedded Software Engineering Report Nr. 30]].
  
 ====== Nächstes Thema ====== ====== Nächstes Thema ======
 [[objektorientierte Programmiersprachen]] [[objektorientierte Programmiersprachen]]