Programmierung

Klasse
Unter einer Klasse (auch Objekttyp genannt) versteht man in der objektorientierten Programmierung
ein abstraktes Modell bzw. einen Bauplan für eine Reihe von ähnlichen Objekten. Die Klasse dient als
Bauplan für die Abbildung von realen Objekten in Softwareobjekte und beschreibt Attribute
(Eigenschaften) und Methoden (Verhaltensweisen) der Objekte. Verallgemeinernd könnte man auch
sagen, dass eine Klasse dem Datentyp eines Objekts entspricht.

Methode
Methoden (englisch method oder member function) sind in der objektorientierten Programmierung
Unterprogramme in der Form von Funktionen oder Prozeduren, die das Verhalten von Objekten
beschreiben und implementieren. Über die Methoden des Objekts können Objekte untereinander in
Verbindung treten.
Das Kernstück jeder objektorientierten Programmierung bildet das Objekt. Allgemein kann man
sagen, dass Objekte Attribute und Methoden enthalten. Dabei sind Attribute
nur Variablen und Konstanten, die Werte aufnehmen können, und beschreiben damit das statische
Wesen des Objektes. Im Gegensatz dazu gibt es die Methoden, die das gesamte dynamische
Verhalten des Objektes oder einer Klasse charakterisieren. Sie enthalten die algorithmische Essenz
des Objektes. In der objektorientierten Programmierung sind Methoden Teil der Definition einer
Klasse.

Konstruktor
Als Konstruktoren und Destruktoren (aus dem Englischen auch kurz ctor bzw. dtor genannt) werden in
der Programmierung spezielle Prozeduren oder Methoden bezeichnet, die beim Erzeugen bzw.
Auflösen von Objekten und Variablen aufgerufen werden. Konstruktoren können
mit Parametern versehen werden, während Destruktoren in der Regel argumentfrei sind.
Durch Konstruktoren und Destruktoren bleibt der Anschein der Atomarität der Erstellung bzw. des
Abbaus gewahrt. Gleichzeitig können bereits bei der Deklaration durch Übergabe von bestimmten
Parametern die Regeln zur Erstellung und Auflösung von Variablen des betreffenden Typs formuliert
werden.
Konstruktoren und Destruktoren kommen zwar in manchen objektorientierten
Programmiersprachen vor, sind aber ein von der objektorientierten Programmierung (OOP)
unabhängiges Konzept, das weder Voraussetzung für OOP ist, noch auf die OOP beschränkt ist. So
kommen Konstruktoren und Destruktoren beispielsweise auch in prozeduralen
Programmiersprachen vor.

Member
In der objektorientierten Programmierung für Eigenschaften (Attribute) und Methoden einer Klasse.

OO Modellierung
Die Grundidee der objektorientierten Modellierung besteht darin, Daten und Funktionen, die auf
diese Daten angewendet werden können, in einem sogenannten Objekt zusammenzufassen und nach
außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich
manipulieren können. Zur Verwaltung gleichartiger Objekte bedient sich die objektorientierte
Modellierung des Konzepts der Klasse.
Variablen (inkl. Größe)
In der Programmierung ist eine Variable ein abstrakter Behälter für einen Wert, der bei der
Ausführung eines Computerprogramm auftritt. Im Normalfall wird eine Variable im Quelltext durch
einen Namen bezeichnet und hat eine Adresse im Speicher des Computers. Der durch eine Variable
repräsentierte Wert und gegebenenfalls auch die Größe kann – im Unterschied zu einer Konstante –
zur Laufzeit des Rechenprozesses verändert werden.
Beispiele in der Programmiersprache C# :

const int i = 3; // Konstante; keine Variable

int j = 3; // Wertevariable
object k = (object)3; // referenzielle Variable auf einen Wert
object o = new object(); // referenzielle Variable auf ein Objekt
object n = null; // referenzielle Variable auf das null-Objekt
(Zeiger auf Speicheradresse 0)
Func<int> f = () => 3; // referenzielle Variable auf eine Funktion

Keyword .NET-Datentyp Speicher Wertebereich Bemerkung

bool System.Boolean 8 bit true oder false

1 byte (0xFF oder 0x00)

byte System.Byte 8 bit 0x0 bis 0xFF

1 byte 0 bis 255

char System.Char 16 bit 0x0 bis 0xFFFF (ein Unicode- einzelnes Unicode-Zeichen innerha
2 byte Zeichen) einfachen Anführungsstrichen (')
0 bis 65.535

decimal System.Decimal 128 bit (-7,9x1028 bis 7,9x1028) Suffix M

16 byte / 10x10(0 bis 28)

double System.Double 64 bit -1,79769313486232x10308 bis Suffix D

8 byte 1,79769313486232x10308

float System.Single 32 bit -3,402823x1038 bis 3,402823x1038 Suffix F

4 byte

int System.Int32 32 bit 0x8000 0000 bis 0x7FFFFFFF

4 byte -2.147.483.648 bis 2.147.483.647

long System.Int64 64 bit 0x8000 0000 0000 0000 bis 0x7FFF Suffix L
8 byte FFFF FFFF FFFF
-9.223.372.036.854.775.808 bis
9.223.372.036.854.775.807

object System.Object

sbyte System.SByte 8 bit 0x80 bis 0x7F

Keyword .NET-Datentyp Speicher Wertebereich Bemerkung

1 byte -128 bis 127

short System.Int16 16 bit 0x8000 bis 0x7FFF

2 byte -32.768 bis 32.767

string System.String Kein oder mehrere Unicode-Zeiche

innerhalb doppelten
Anführungsstrichen (") - oder nul

uint System.UInt32 32 bit 0x0 bis 0xFFFF FFFF

4 byte 0 bis 4.294.967.295

ulong System.UInt64 64 bit 0x0 bis 0xFFFF FFFF FFFF FFFF Suffix UL (U, L)
8 byte 0 bis 18.446.744.073.709.551.615

ushort System.UInt16 16 bit 0x0 bis 0xFFFF

2 byte 0 bis 65.535

Wert von Verweis DT

Datenkapselung
Datenkapselung ist ein lange bekanntes Prinzip innerhalb der strukturierten und modularen
Programmierung. Zentrales Modell ist hier der abstrakte Datentyp, in dem Daten in einer
Datenstruktur zusammengefasst sind, auf die nur über festgelegte Zugriffsfunktionen (Prozeduren)
zugegriffen werden kann. In der tatsächlichen Programmierung wird der abstrakte Datentyp auf
verschiedene Weisen implementiert. Ein anderes Beispiel in modernen Programmiersprachen ist das
Verbergen von Daten innerhalb von Gültigkeitsbereichen. Jede Teilstruktur eines Programms
(Hauptblock, Prozeduren, Funktionen, Unterprogramme, …) definiert einen solchen Bereich, so dass
eine Gültigkeitshierarchie entsteht. Deklarierte Daten sind nur innerhalb des umgebenden und in
allen tieferen Bereichen sichtbar und gültig. Für einen höheren Bereich bleiben sie verborgen.
Vererbung
Die Vererbung (englisch inheritance) ist eines der grundlegenden Konzepte der Objektorientierung
und hat große Bedeutung in der Softwareentwicklung. Die Vererbung dient dazu, aufbauend auf
existierenden Klassen neue zu schaffen, wobei die Beziehung zwischen ursprünglicher und neuer
Klasse dauerhaft ist. Eine neue Klasse kann dabei eine Erweiterung oder eine Einschränkung der
ursprünglichen Klasse sein. Neben diesem konstruktiven Aspekt dient Vererbung auch der
Dokumentation von Ähnlichkeiten zwischen Klassen, was insbesondere in den frühen Phasen des
Softwareentwurfs von Bedeutung ist. Auf der Vererbung basierende Klassenhierarchien spiegeln
strukturelle und verhaltensbezogene Ähnlichkeiten der Klassen wider. Die vererbende Klasse wird
meist Basisklasse (auch Super-, Ober- oder Elternklasse) genannt, die erbende abgeleitete Klasse
(auch Sub-, Unter- oder Kindklasse). Den Vorgang des Erbens nennt man meist Ableitung oder
Spezialisierung, die Umkehrung hiervon Generalisierung, was ein vorwiegend auf die Modellebene
beschränkter Begriff ist. In der Unified Modeling Language (UML) wird eine Vererbungsbeziehung
durch einen Pfeil mit einer dreieckigen Spitze dargestellt, der von der abgeleiteten Klasse zur
Basisklasse zeigt. Geerbte Attribute und Methoden werden in der Darstellung der abgeleiteten Klasse
nicht wiederholt.

Polymorphie
Polymorphie oder Polymorphismus (griechisch für Vielgestaltigkeit) ist ein Konzept in der
objektorientierten Programmierung, das ermöglicht, dass ein Bezeichner abhängig von seiner
Verwendung Objekte unterschiedlichen Datentyps annimmt. In älteren typisierten
Programmiersprachen wird dagegen jedem Namen und jedem Wert im Quelltext eines Programms
höchstens ein Typ zugeordnet. Dies bezeichnet man als Monomorphie.
Die Polymorphie der objektorientierten Programmierung ist eine Eigenschaft, die immer im
Zusammenhang mit Vererbung und Schnittstellen (Interfaces) auftritt. Eine Methode ist polymorph,
wenn sie in verschiedenen Klassen die gleiche Signatur hat, jedoch erneut implementiert ist.

Interfaces
Eine Schnittstelle (englisch interface oder protocol) definiert in der objektorientierten
Programmierung, welche Methoden in den unterschiedlichen Klassen u. Ä. vorhanden sind oder
vorhanden sein müssen. Sie legt die Namen und die Signatur der Methoden, also die Parametertypen
und den Rückgabetyp, fest.
Schnittstellen stellen eine Garantie über die in einer Klasse vorhandenen Methoden dar. Sie geben
an, dass alle Objekte, die diese Schnittstelle besitzen, gleich behandelt werden können. In einigen
Programmiersprachen, die keine Mehrfachvererbung unterstützen, z. B. Java, können Schnittstellen
verwendet werden, um Kompatibilitäten zwischen Klassen zu definieren, die nicht voneinander
erben: Die Schnittstellenbeziehungen sind nicht an den strengen Klassenbaum gebunden. Dazu
werden Schnittstellendeklarationen häufig explizit als solche markiert (etwa mit dem Schlüsselwort
interface). Als Ersatz für Mehrfachvererbung eignen sich Schnittstellen allerdings nur eingeschränkt,
da sie lediglich Methoden und deren Parameter definieren und keine direkte Vererbung von
Funktionalität ermöglichen.
Delegation

Petterns (Singleton)

Compiler
Ein Compiler (auch Kompilierer; von englisch compile ‚zusammentragen‘ bzw. lateinisch compilare
‚aufhäufen‘) ist ein Computerprogramm, das Quellcodes einer bestimmten Programmiersprache in
eine Form übersetzt, die von einem Computer (direkter) ausgeführt werden kann. Daraus entsteht
ein mehr oder weniger direkt ausführbares Programm. Davon zu unterscheiden sind Interpreter, etwa
für frühe Versionen von BASIC, die keinen Maschinencode erzeugen. Teils wird zwischen den
Begriffen Übersetzer und Compiler unterschieden. Ein Übersetzer übersetzt ein Programm aus einer
formalen Quellsprache in ein semantisches Äquivalent in einer formalen Zielsprache. Compiler sind
spezielle Übersetzer, die Programmcode aus problemorientierten Programmiersprachen,
sogenannten Hochsprachen, in ausführbaren Maschinencode einer bestimmten Architektur oder
einen Zwischencode (Bytecode, p-Code oder .NET-Code) überführen. Diese Trennung zwischen den
Begriffen Übersetzer und Compiler wird nicht in allen Fällen vorgenommen.

Interpreter
Als Interpreter wird ein Computerprogramm bezeichnet, das eine Abfolge von Anweisungen
anscheinend direkt ausführt, wobei das Format der Anweisungen vorgegeben ist. Der Interpreter liest
dazu eine oder mehrere Quelldateien ein, analysiert diese und führt sie anschließend Anweisung für
Anweisung aus, indem er den dafür vorgesehenen Programmcode (eventuell über Zwischenschritte
schließlich als Maschinencode für das jeweilige Computersystem) direkt ausführt. Interpreter sind
deutlich langsamer als Compiler, bieten im Allgemeinen jedoch eine bessere Fehleranalyse.

Debugger
Ein Debugger (von engl. de- (Präfix; dt. ent-, aus-) im Sinne von entfernen und engl. bug im Sinne von
Programmfehler) ist ein Werkzeug zum Diagnostizieren und Auffinden von Fehlern in
Computersystemen, dabei vor allem in Programmen, aber auch in der für die Ausführung benötigten
Hardware. Debugging bezeichnet die Tätigkeit, solche Fehler zu diagnostizieren und aufzufinden, sei
es unter Verwendung eines Debuggers oder anderer Methoden.

Serialisieren/Deserialisieren (XML und JSON)

Prozedurale PS und OOP

EVA-Prinzip
Viele Programme lassen sich nach dem EVA-Prinzip strukturieren. EVA steht hier für Eingabe -
Verarbeitung - Ausgabe. In einem Eingabeteil werden die Benutzereingaben von entsprechenden
Variablen erfasst. In dem darauffolgenden Verarbeitungsteil werden die von den Variablen
verwalteten Daten weiterverarbeitet. In einem Ausgabeteil werden abschließend berechnete
Ergebnisse auf dem Bildschirm ausgegeben.
SOLID-Prinzip
Für eine Gruppe dieser Prinzipien wurde von Robert C. Martin das Akronym “SOLID” geprägt. Diese
Prinzipien gemeinsam angewandt führt laut Robert C. Martin zu einer höheren Wartbarkeit und
somit Lebensdauer von Software. Diese Prinzipien sind das “Single Responsibility Prinzip”, das
“Open-Closed Prinzip”, das “Liskovsches Substitutionsprinzip”, das “Interface Segregation Prinzip”
und das “Dependency Inversion Prinzip”.

Single-Responsibility-Prinzip
Das Single-Responsibility-Prinzip besagt, dass jede Klasse nur eine einzige Verantwortung haben solle.
Verantwortung wird hierbei als „Grund zur Änderung“ definiert:
Mehr als eine Verantwortung für eine Klasse führt zu mehreren Bereichen, in denen zukünftige
Änderungen notwendig werden können. Die Wahrscheinlichkeit, dass die Klasse zu einem späteren
Zeitpunkt geändert werden muss, steigt zusammen mit dem Risiko, sich bei solchen Änderungen
subtile Fehler einzuhandeln. Dieses Prinzip führt in der Regel zu Klassen mit hoher Kohäsion, in denen
alle Methoden einen starken gemeinsamen Bezug haben.

Open-Closed-Prinzip
Das Open-Closed-Prinzip besagt, dass Software-Einheiten (hier Module, Klassen, Methoden usw.)
Erweiterungen möglich machen sollen (dafür offen sein), aber ohne dabei ihr Verhalten zu ändern
(ihr Sourcecode und ihre Schnittstelle sollte sich nicht ändern). Es wurde 1988 von Bertrand Meyer
folgendermaßen formuliert:
Eine Erweiterung im Sinne des Open-Closed-Prinzips ist beispielsweise die Vererbung. Diese
verändert das vorhandene Verhalten einer Klasse nicht, erweitert sie aber um zusätzliche Funktionen
oder Daten. Überschriebene Methoden verändern auch nicht das Verhalten der Basisklasse, sondern
nur das der abgeleiteten Klasse. Folgt man weiter dem Liskovschen Substitutionsprinzip, verändern
auch überschriebene Methoden nicht das Verhalten, sondern nur die Algorithmen.

Liskovsches Substitutionsprinzip
Das Liskovsche Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip fordert, dass eine Instanz einer
abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor
sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich
um ein Objekt eines Subtyps handelt. Es wurde 1993 von Barbara Liskov und Jeannette Wing
formuliert. In einem nachfolgenden Artikel wurde es folgendermaßen formuliert:
Damit ist garantiert, dass Operationen vom Typ Superklasse, die auf ein Objekt des Typs Subklasse
angewendet werden, auch korrekt ausgeführt werden. Dann lässt sich stets bedenkenlos ein Objekt
vom Typ Superklasse durch ein Objekt vom Typ Subklasse ersetzen. Objektorientierte
Programmiersprachen können eine Verletzung dieses Prinzips, die aufgrund der mit der Vererbung
verbundenen Polymorphie auftreten kann, nicht von vornherein ausschließen. Häufig ist eine
Verletzung des Prinzips nicht auf den ersten Blick offensichtlich.

Interface-Segregation-Prinzip
Das Interface-Segregation-Prinzip dient dazu, zu große Interfaces aufzuteilen. Die Aufteilung soll
gemäß den Anforderungen der Clients an die Interfaces gemacht werden – und zwar derart, dass die
neuen Interfaces genau auf die Anforderungen der einzelnen Clients passen. Die Clients müssen also
nur mit Interfaces agieren, die das und nur das können, was die Clients benötigen.
Mit Hilfe des Interface-Segregation-Prinzips ist es möglich eine Software derart in entkoppelte und
somit leichter refaktorisierbare Klassen aufzuteilen, dass zukünftige fachliche oder technische
Anforderungen an die Software nur geringe Änderungen an der Software selbst benötigen.
Dependency-Inversion-Prinzip
Das Dependency-Inversion-Prinzip beschäftigt sich mit der Reduktion der Kopplung von Modulen. Es
besagt, dass Abhängigkeiten immer von konkreteren Modulen niedriger Ebenen zu abstrakten
Modulen höherer Ebenen gerichtet sein sollten.

“A. High-level modules should not depend on low level modules. Both should depend on
abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.”

„A. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von
Abstraktionen abhängen.
B. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“

Damit ist sichergestellt, dass die Abhängigkeitsbeziehungen immer in eine Richtung verlaufen, von
den konkreten zu den abstrakten Modulen, von den abgeleiteten Klassen zu den Basisklassen. Damit
werden die Abhängigkeiten zwischen den Modulen reduziert und insbesondere zyklische
Abhängigkeiten vermieden.
Multi-paradigm

High-level

General-purpose

Type safety

Concurrency

Reference counting

Data races

Strong typing

Lexically scoped

Imperative

Declarative

Functional

Generic

Component-oriented

Compiled programing language