nicht angemeldet
moin,
Für kleinere Projekte ist es durchaus legitim, mehr oder weniger alles in einem Topf zu kochen. Aber wenn es darauf ankommt, dass man die einzelnen Teile automatisch testen lassen können möchte, muss man die Module unabhängig voneinander schreiben. Test Driven Development ist gerade für größere Projekte wichtig für die Qualität, denn je größer ein Projekt wird, desto schwieriger wird es, den Übersicht über alle Abhängigkeiten zu bewahren. Nicht nur um diese Abhängigkeiten übersichtlich zu gestalten, sondern eben auch, um die Module einzeln testen zu können, ist eine Trennung sehr wohl sinnvoll.
Natürlich besteht auch bei voneinander abhängigen Modulen die Gefahr des Verlust der Übersicht, da hast Du schon recht. Forster (Perl Module) empfiehlt dazu, die Hierarchie nicht von "oben" nach "unten" zu designen, sondern genau andersherum, also mit den abgeleiteten Klassen zu beginnen.
Damit lassen sich die Aufgaben genausogut verteilen, wie im Falle voneinander unabhängiger Klassen, besser noch: Es greift Eines ins Andere, Schnittstellen sind einheitlich definiert und der Code bleibt übersichtlich sowie modular. Beispiel:
date
date::calc
date::calc::html
Der (die) Entwickler von 'date::calc::html' designen nur die Darstellung, fehlt z.B. css, ist das nur eine Angelegenheit von 'date::calc::html'. Fehlt jedoch beispielsweise ein Datenfeld in der übergeordneten Instanz (z.B. der Wochentag), liegt die Zuständigkeit in 'date::calc'. Gäbe es keine Hierarchie, müssten sich die html-Designer mit einer Formel rumplagen, die den Wochentag berechnet.
Es ist mit OOP wie mit anderen Dingen: Sinnvoll und zweckbestimmend einsetzen.
Grüße an Alle,
Hotti