Login
Newsletter
Werbung

Thema: Objektorientierte Programmierung: Teil 1 – OOP in der Praxis

1 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von hans wurst am So, 15. April 2012 um 15:16 #

>Du kannst das drehen wie Du willst: Klassendiagramme (und darauf basierende) machen für
>Sprachen ohne Klassen einfach keinen Sinn!

Für Javascript sehe ich keine Hindernisse, aber da brauchen wir glaub ich nicht drüber zu diskutieren.

Aber sagen wir, wir reden von C: darin soll eine Software implementiert werden, an der 5 Leute arbeiten. Die Software ist außerdem so groß, dass es keinen Sinn macht, dass sich jeder in allen Code-Teilen perfekt auskennen. Besser ist, wenn jeder sich auf bestimmte Funktionalitäten spezialisiert. Außerdem ist die Software multithreaded.

Da sagt der Verantwortliche natürlich: die Software muss irgendeine Modularität aufweisen. Diese Modularität muss gut isolieren. Also etwa verhindern, dass in Modul A Variablen von Modul B geändert werden, die überhaupt nicht in den Zuständigkeitsbereich von A fallen.

Da die Software Multithreaded ist, soll ohnehin verhindert werden, dass Funktionen in Modul A Variablen von B ändern können. Und sei es ganz über Umwege durch interne Hilfsfunktionen, die für sich genommen der geringeren Komplexität wegen nicht thread-safe sind, etwa:

/* modul_b.c */
/* ... */
void increment() {
foo++;
}
/* ... */

Da kannst du es drehen wie du willst, aber letztendlich brauchst du dafür ein zu Klassen isomorphes Konzept. C kennt weder Namespaces, Module oder Klassen. Funktionen sind immer global und öffentliche Variablen im Prinzip auch. (Außer man benutzt Funktionenzeiger.)

Im Linux-Kernel wird das zB dadurch simuliert, dass alle Funktionen immer ein Prefix haben. Z.B. in kernel/audit.c fangen alle Funktionen und öffentliche Variablen mit audit_ an.

Oder schau dir den struct audit_buffer an:
- es gibt die Funktionen audit_buffer_free (Destruktor) und audit_buffer_alloc (Konstruktor)
- die meistens Funktionen (mit nicht-trivialer Funktionalität) haben audit_buffer als erstes Argument

Natürlich kannst du jetzt kommen und sagen: aha, was was ist dann mit Polymorphie und Vererbung? Öffentliche Vererbung und Polymorphie kann man durchaus als Bad-Practise ansehen. Siehe zB hier. Manche C++-Experten raten sogar komplett auf öffentliche Vererbung zu Verzichten und stattdessen die zu erbenden Klassen in Instanzvariablen zu stecken. Die Kapselung ist so viel überschaubarer. Stattdessen soll man auf Interfaces bzw. abstrakte Klassen setzen (Google Go etwa verfolgt genua dieses Konzept, es hat keine Vererbung wie man sie von Java oder C++ kennt.)

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung