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/02/07 09:45]
127.0.0.1 Externe Bearbeitung 		basiskonzepte [2019/07/27 16:00] (aktuell)
huwi [Lange Rede kurzer Sinn]
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**. 
  
->>>{{:basiskonzepte:abstarktion.jpg|}}+>{{:basiskonzepte:abstarktion.jpg|}}
  
 ===== 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 das Programm selbst, die **Applikation**, vielleicht eine bestimmte Schaltfläche, ein **Button** oder eine **Liste** usw.. Diese Objekte besitzen konkrete Eigenschaften und typisches Verhalten. Die Applikation hat eine bestimmte Hintergrundfarbe, die Schaltfläche kann gedrückt werden und die Liste hat einen dünnen Rahmen. 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 das Programm selbst, die **Applikation**, vielleicht eine bestimmte Schaltfläche, ein **Button** oder eine **Liste** usw.. Diese Objekte besitzen konkrete Eigenschaften und typisches Verhalten. Die Applikation hat eine bestimmte Hintergrundfarbe, die Schaltfläche kann gedrückt werden und die Liste hat einen dünnen Rahmen. 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.**
  
->>>{{:basiskonzepte:objekt.jpg|}}+>{{:basiskonzepte:objekt.jpg|}}
  
 ===== 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 **Button**. Davon haben wir in unserer Anwendung schon mal zwei Stück. Um diese zu unterscheiden, geben wir jedem noch einen individuellen Namen, zum Beispiel **Ende** und **Hilfe**. //Button// steht also als Begriff für alle Schaltflächen mit den entsprechenden gleichen Eigenschaften. Der Fachmann bezeichnet so etwas als Kategorie oder auch als //Klasse//. Die beiden Objekte //Button Ende// und //Button Hilfe// sind Bausteine unseres Systems und gehören zur Klasse (Gruppe) der Schaltflächen (Button). Unser oberschlauer Fachmann bezeichnet diese beiden konkreten Objekte auch gern als //Instanzen// der Klasse //Button//. Ü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 **Button**. Davon haben wir in unserer Anwendung schon mal zwei Stück. Um diese zu unterscheiden, geben wir jedem noch einen individuellen Namen, zum Beispiel **Ende** und **Hilfe**. //Button// steht also als Begriff für alle Schaltflächen mit den entsprechenden gleichen Eigenschaften. Der Fachmann bezeichnet so etwas als Kategorie oder auch als //Klasse//. Die beiden Objekte //Button Ende// und //Button Hilfe// sind Bausteine unseres Systems und gehören zur Klasse (Gruppe) der Schaltflächen (Button). Unser oberschlauer Fachmann bezeichnet diese beiden konkreten Objekte auch gern als //Instanzen// der Klasse //Button//. Ü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 Bausteine einen Gruppennamen (Klassennamen) und beschreiben die gemeinsamen Merkmale (Attribute und Operationen). Objekte sind Instanzen einer Klasse.**+>**Wir geben einer Menge gleichartiger Bausteine einen Gruppennamen (Klassennamen) und beschreiben die gemeinsamen Merkmale (Attribute und Operationen). Objekte sind Instanzen einer Klasse.**
  
->>>{{:basiskonzepte:klassen.jpg|}}+>{{:basiskonzepte:klassen.jpg|}}
  
 ===== Vererbung ===== ===== Vererbung =====
 Schaltflächen haben mit Listen und Eingabefeldern eine Menge gemeinsam. So kann man diese zum Beispiel sehen und ihnen den Eingabefokus geben. 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 //Steuerelement (Control)// sein. Das man für eine Schaltfläche noch einen visuellen Effekt beim betätigen benötigt, ist etwas Spezielles und gehört nicht zu den gemeinsamen Merkmalen. Ein solches spezielles Merkmal wird dann auch nicht in der Basisklasse //Control// sondern in einer speziellen Klasse, die zum Beispiel eben genau //Button// heißen könnte, programmiert. Jedoch die Masse an Merkmalen erbt die Schaltfläche von ihrer Basisklasse. Diese spezialisierten Klassen nennt der Fachmann auch Ableitungen. Umgangssprachlich lässt sich Vererbung mit **"ist ein/ist eine"** ausdrücken. Für die Ableitungen //Button, ListBox, Edit// stellt die Basisklasse //Control// eine Verallgemeinerung (Generalisierung) dar.  Schaltflächen haben mit Listen und Eingabefeldern eine Menge gemeinsam. So kann man diese zum Beispiel sehen und ihnen den Eingabefokus geben. 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 //Steuerelement (Control)// sein. Das man für eine Schaltfläche noch einen visuellen Effekt beim betätigen benötigt, ist etwas Spezielles und gehört nicht zu den gemeinsamen Merkmalen. Ein solches spezielles Merkmal wird dann auch nicht in der Basisklasse //Control// sondern in einer speziellen Klasse, die zum Beispiel eben genau //Button// heißen könnte, programmiert. Jedoch die Masse an Merkmalen erbt die Schaltfläche von ihrer Basisklasse. Diese spezialisierten Klassen nennt der Fachmann auch Ableitungen. Umgangssprachlich lässt sich Vererbung mit **"ist ein/ist eine"** ausdrücken. Für die Ableitungen //Button, ListBox, Edit// stellt die Basisklasse //Control// eine Verallgemeinerung (Generalisierung) dar. 
  
->>>**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.**
  
->>>{{:basiskonzepte:generalisierung.jpg|}}+>{{:basiskonzepte:generalisierung.jpg|}}
  
  
Zeile 48: Zeile 48:
 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 dieser 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 dieser 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 54: Zeile 54:
 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 objektorientierten Programmiersprache komplexe Klassen aus einfachen Klassen 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 objektorientierten Programmiersprache komplexe Klassen aus einfachen Klassen 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.**
  
->>>{{:basiskonzepte:aggregation.jpg|}}+>{{:basiskonzepte:aggregation.jpg|}}
  
 ===== Nachricht ===== ===== Nachricht =====
 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 das System mit seinen Bausteinen über diese Nachrichten. Das der Aufruf von Operationen Nachricht und nicht Befehl 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 //com3// zwar die Nachricht //open// sendet, dieses aber nicht darauf reagiert. Solch ein Verhalten muss kein Programmierfehler sein. Das Objekt //com3// kann zum Beispiel festgestellt haben, dass gar kein Gerät angeschlossen ist und entscheidet für sich selbst, zur Sicherheit, den Port geschlossen zu halten, 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 das System mit seinen Bausteinen über diese Nachrichten. Das der Aufruf von Operationen Nachricht und nicht Befehl 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 //com3// zwar die Nachricht //open// sendet, dieses aber nicht darauf reagiert. Solch ein Verhalten muss kein Programmierfehler sein. Das Objekt //com3// kann zum Beispiel festgestellt haben, dass gar kein Gerät angeschlossen ist und entscheidet für sich selbst, zur Sicherheit, den Port geschlossen zu halten, ohne erst mal um Genehmigung zu bitten.
  
->>>**Das System arbeitet mit seinen Bausteinen zusammen, indem es mit diesen Nachrichten austauscht. Der Empfänger einer Nachricht entscheidet was getan wird.**+>**Das System arbeitet mit seinen Bausteinen zusammen, indem es mit diesen Nachrichten austauscht. Der Empfänger einer Nachricht entscheidet was getan wird.**
  
 ===== Assoziation ===== ===== Assoziation =====
 Manchmal ist es erforderlich, das 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, das 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.**
  
  
 ===== Lange Rede kurzer Sinn ===== ===== Lange Rede kurzer Sinn =====
  
->>>**Unsere natürliche Sprache ist objektorientiert!**+>**Unsere natürliche Sprache ist objektorientiert!**
  
->>><code>+><code>
 Wenn die Schaltfläche gedrückt wird, zeige die Hilfe an. Wenn die Schaltfläche gedrückt wird, zeige die Hilfe an.
 If the button is pressed then shows the help. If the button is pressed then shows the help.
Zeile 80: Zeile 80:
 </code> </code>
  
->>>Zum Vertiefen: [[http://www.willert.de/assets/Newsletter/ESER30-OOP-V1.1.pdf|Embedded Software Engineering Report Nr. 30]]. +>Zum Vertiefen: {{ :basiskonzepte:eser-30-oop-v1.1.pdf |}}
 ====== Nächstes Thema ====== ====== Nächstes Thema ======
   * [[UML]]   * [[UML]]
   * [[http://www.mysvl.de/wiki/doku.php?id=start|zurück zur Übersicht]]   * [[http://www.mysvl.de/wiki/doku.php?id=start|zurück zur Übersicht]]