Login
Newsletter
Werbung

Do, 12. April 2012, 15:00

Objektorientierte Programmierung: Teil 1 – OOP in der Praxis

Der Begriff der objektorientierten Programmierung (kurz OOP) existiert schon eine ganze Weile. Wer zuvor prozedural programmiert hat, erwischt sich beim Übergang zu OOP öfters dabei, wie er die früheren Funktionen einfach mit einer Klasse umgibt und dies als objektorientierte Programmierung verkauft. Die Artikelreihe soll an einem einfachen Beispiel zeigen, was man in so einem Fall besser machen könnte.

Hinweis: Für den Artikel wird erwartet, dass man weiß, was Klassen, Interfaces, Attribute und Operationen sind. Es schadet auch nicht, ein paar Dinge über Unified Modeling Language (UML) zu wissen, wobei die UML-Diagramme auch ohne großes Vorwissen verstanden werden können.

Einleitung

Bevor auch nur ein Satz zur »richtigen« Anwendung von objektorientierter Programmierung fällt, soll vorausgeschickt werden, dass es keine absolut richtige Programmierung gibt. Ähnlich wie bei Buchautoren sind Programmierer und deren Programmierstile sehr verschieden. Stellt man zehn Entwicklern eine (komplexe) Aufgabe, kann man sicher sein, dass man zehn verschiedene Lösungen erhalten wird und von jeder wird der Entwickler in der Regel auch sagen, dass sie gut sei.

Dennoch haben sich im Laufe der Zeit verschiedene Programmierparadigmen und -muster herausgebildet, die allgemein als sinnvoll anerkannt werden. Zu dem Thema gibt es entsprechend viele Bücher, am bekanntesten ist wahrscheinlich das Buch der »Gang of Four« Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides namens »Design Patterns. Elements of Reusable Object-Oriented Software«. Das Buch gibt es auch auf Deutsch unter dem Titel »Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software« und beschreibt zahlreiche Entwurfsmuster, die beim Design objektorientierter Software benutzt werden können.

Neben diesem Buch wurde für die Artikelreihe auch noch auf das sehr gute »Head First Design Patterns« von Eric Freeman, Elisabeth Freeman, Bert Bates und Kathy Sierra zurückgegriffen, welches ebenfalls auf Deutsch unter dem Titel »Entwurfsmuster von Kopf bis Fuß« erhältlich ist (siehe Rezension des Buches).

Der Artikel soll entsprechend der Bücher nicht zwingend erklären, was gut und schlecht ist. Wenn eine Implementierung ein Problem löst, ist sie prinzipiell gut. Dennoch kann sie Nachteile haben, die es bei einem anderen Lösungsansatz nicht gegeben hätte. Dies hängt aber auch immer von den eigenen Präferenzen ab. Bei einem Programm, was man einmalig schreibt und welches danach ganz sicher nie wieder angepasst oder erweitert werden muss (»Wegwerfsoftware«), ist es eher nicht sinnvoll, zu viel Zeit in ein gutes Software-Design zu stecken – außer man hat extrem viel Spaß daran. Bei langlebiger und wartungsintensiver Software, wie sie in der Regel bei Firmen zum Einsatz kommt, kann ein gutes Software-Design aber von Vorteil sein.

Das Design wird mithilfe des UML-Programms Visual Paradigm erstellt und dargestellt (siehe »UML-Programme im Test«, freiesMagazin 02/2012). Für die beispielhafte Umsetzung wird C++ benutzt. Jeder Leser kann die Aufgaben aber auch in anderen OOP-fähigen Sprachen wie Java, Python, Perl oder Ruby nachprogrammieren.

Im Laufe der Reihe wird das anfängliche Beispiel dann verbessert und soll immer unter folgenden Gesichtspunkten betrachtet werden:

  • Anzahl der Abhängigkeiten
  • Verantwortlichkeit einer Klasse
  • Bedeutung für Wartbarkeit und Erweiterbarkeit

Hinweis: Da ich C++-Entwickler bin, sind ggf. einige Lösungsaspekte allein der Sprache geschuldet. Bei anderen Programmiersprachen ergibt sich ein Problem gar nicht oder man würde es anders lösen. Es wird aber versucht, sprachunabhängige Lösungen aufzuzeigen.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung