Philosophische Grundlagen der objekt-orientierten Softwareentwicklung

von Rudolf Weber

Warum Philosophie ?

Die Philosophie beschäftigt seit den Anfängen bei den Griechen mit der Beschreibung der Welt. Die Mythologie/Theologie hingegen mit dem Sinn und Offenbarungen.

In der Informatik wollen wir Teile unserer Lebenswelt automatisieren. Dazu müssen wir diese verstehen und formal beschreiben, getreu nach Prof. Wedekind (Uni Erlangen): Wer automatisieren will, muß formalisieren. In den letzten 100 Jahren hat die Philosopie eine sprachkritische Wendung gemacht, was dazu geführt hat, daß die Ansprüche der Philosophie sehr bescheiden geworden sind.

Warum sich nicht die Ergebnisse zunutze machen ?
Insbesondere die Logik und Wissenschaftstheorie sind interessant. Diese sind grundlegend für alle Wissenschaften und sollten in den Universitäten ein Pflichtfach für alle Studiengänge sein und auch in der Elementarschule intensiv behandelt werden.
Wir wollen uns damit auch dem interdiziplinären Dialog öffnen, insbesondere mit den Fachwissenschaften, denn ohne Anwendungen ist die Computerei sinnlos.

Überblick

  1. Die Welt besteht aus Objekten
  2. Objekte sind Exemplare von Objektschablonen (Klassen). Die Exemplarbeziehung ist eine erste Stufe der Abstraktion.
  3. Was ist Abstraktion ?
  4. Objekte haben Attribute von den Objektschablonen/Kassen
  5. Objekte haben Zustände, die durch Operationen geändert werden
    Abläufe (Bogen zur prozeduralen Programierung)
  6. Generalisierung/Spezialisierung von Klassen, Subordination von Begriffen, Vererbung. Dies ist eine zweite Stufe der Abstraktion
  7. Zusammensetzen von Klassen Teil Ganze-Beziehung
  8. Granularität von Objekten
  9. Systeme: Wichtig sind die Beziehungen zwischen den Objekten
  10. Begriffswörter haben einen Kontext/Gütigkeitsbereich
  11. Schichtenmodell: Systeme (nicht nur) in der Informatik sind in Schichten aufgebaut
  12. Entwurfsmuster bilden eine Sprache, mit der man über Softwaredesign sprechen kann.
  13. Architektur bestimmt den übergeordneten Aufbau und die Grundlinien eines Systems
  14. Mit Use-Cases stellt man fest, was man eigentlich von einem zu modellierenden System haben will. Damit hat man eine Grundlage um Objekte/Klassen zielgerichtet zu suchen.

Fortgeschrittenes

Literatur und weiteres

Verwendete Literatur
OO-FAQ
Aus der USENET-comp.object-Newsgroup entstanden
German Object Oriented Association Linkage
Mailingliste über OO-Technologie, gesponsert aber keine WWW-Seiten dazu
SDL - System Design Langiages
Designsprachen aus der Telekommunikation - entwickeln sich zu Spezialprofilen der UML

Designprinzipien

SOLID Design

SRP - Single responsibility principle
eine Klasse soll nur eine einzige Verantwortung haben
OCP - open/close principle
offen für Erweiterung, geschlossen für Änderung
LSB - Liskov substitution prinziple
Klasseninstanzen sollen durch Instanzen von Unterklassen ersetzt werden können ohne die Korrektheit des Programmes zu ändern
ISP - Interface segregation principle
für jeden Client ein eigene Schnittstelle statt eine Allzweckschnittstelle für alle.
DIP - Dependency Inversion Principle
eine Klasse soll von Abstrakten Schnittstellen abhängen, nicht von konkreten Implementierungen

weitere

Gesetz von Demeter
minimales Wissen einer Klasse ist Vorraussetzung für lose Kopplung, mehrere Zugriffstufen sind tabu

Rudolf Weber Informatik- und Netzwerkverein Ravensburg e.V