Objektorientiert oder nicht?

[kahlchen]

Hallo,
ich muss für eine Arbeit eine webbasierende Anwendung auf WAMP (P für PHP) entwickeln. Diese soll Inventar verwalten und nur im Intranet laufen.
Wie entscheide ich nun wie ich entwickle? Objektorientiert oder nicht? Framework ala CakePHP benutzen oder nicht?

[DanMan]

Nun, objektorientertes Programmieren bedeutet eingangs erst mal einen Mehraufwand. Wenn es also nur was kleines sein wird, dann kannst du es dir evtl. sparen. Wenns was größeres geben soll, dann zahlt es sich meist im späteren Verlauf aus alles modular zu haben. Gleiches gilt für Frameworks.

[kahlchen]

Naja, es wird nicht besonders groß aber sollte eben sehr sehr ordentlich alles sein. Ist die Huaptaufgabe meiner Diplomarbeit.

[Coda]

Dann kannst du dir die Frage auch selbst beantworten.

[DanMan]

Naja, es wird nicht besonders groß aber sollte eben sehr sehr ordentlich alles sein. Ist die Hauptaufgabe meiner Diplomarbeit.
Wenn du irgendwas mit Programmieren studierst, dann wollen die wohl sehen, was du so kannst, nehm ich mal an. Also würde es sich dann schon anbieten objektorientiert zu programmieren. Andererseits kann man auch mit Kanonen auf Spatzen schießen, was man dir auch wieder negativ auslegen könnte...

[kahlchen]

Dann kannst du dir die Frage auch selbst beantworten.

Okay :)
Danke.

[Gast]

Nun, objektorientertes Programmieren bedeutet eingangs erst mal einen Mehraufwand.

Was ist dass denn für eine Aussage? Beziehst du das nur auf PHP oder wolltest du nurmal so allgemein etwas sagen?

[darph]

Was ist dass denn für eine Aussage? Beziehst du das nur auf PHP oder wolltest du nurmal so allgemein etwas sagen?
Er hat doch Recht. Die ganze Modellierungsgeschichte, die ganzen Klassen zu definieren und deren Interfaces festzulegen - das ist ein gewaltiger Mehraufwand, sehr sich später amortisiert, weil man dann relativ bequem mit den Objekten hantieren kann. Bei kleineren Projekten kann es aber sein, daß man fertig ist, bevor es sich amortisiert hat, so daß hier ein einfaches "dahinprogrammieren" schneller gewesen wäre.

Gerade PHP läßt einem natürlich hier alle Freiheiten, den Tradeoff zwischen Eleganz im Design und Effizienz in der Ausführung (damit meine ich nicht die Laufzeit, die ist in den meisten Fällen eh irrelevant) selbst zu bestimmen.

[Gast]

Er hat doch Recht. Die ganze Modellierungsgeschichte, die ganzen Klassen zu definieren und deren Interfaces festzulegen - das ist ein gewaltiger Mehraufwand ...

Die Frage ist doch, wo Objektorientierung anfängt. Warum glauben so viele Leute eigentlich immer, dass man erst etwas groß modellieren müßte, um die Vorteile von OO nutzen zu können. Es langt doch, wenn man vorhandene Bibliotheken auch für kleine Aufgaben nutzt. Das ist in der Softwareentwicklung doch die eigentliche Kunst.

[Monger]

Objektorientiertes Design hat erstmal nichts mit objektorientiertem Programmieren zu tun.

Kapselung z.B. lässt sich grundsätzlich mal in jeder Sprache mehr oder weniger gut umsetzen. Strukturierter, robuster, wartbarer Code ist grundsätzlich mal vernünftig. Das stellt natürlich erstmal einen Mehraufwand dar (Qualität hat halt ihren Preis), aber Code lebt meistens länger als man denkt, und dann zahlt sich sowas aus.

Immer dran denken: man schreibt jede Codezeile mindestens dreimal.

[Gast]

Die Frage ist doch, wo Objektorientierung anfängt. Warum glauben so viele Leute eigentlich immer, dass man erst etwas groß modellieren müßte, um die Vorteile von OO nutzen zu können. Es langt doch, wenn man vorhandene Bibliotheken auch für kleine Aufgaben nutzt. Das ist in der Softwareentwicklung doch die eigentliche Kunst.

Ich sehe das ähnlich. Die Frage ist doch, wo OO anfängt, auch wenn man's nicht selbst bewusst implementiert. Alle aktuellen Frameworks / Entwicklungsumgebungen sind doch hochgradig objekt orientiert aufgebaut. Selbst wenn sie vielleicht nur irgendwelche C Konstrukte kapseln. Ob der Entwickler dann ebenfalls oo programmiert oder alles der Latte nach in irgendwelche Handler reinklatscht, steht ja auf einem anderen Blatt.

[DanMan]

Was ist dass denn für eine Aussage? Beziehst du das nur auf PHP oder wolltest du nurmal so allgemein etwas sagen?
darph hat mir die Antwort ja quasi schon vorweg genommen.

Wenn man auf Frameworks zurückgreifen kann/will, dann erspart das einem nur dann die Modellierungs-Arie im Voraus, wenn man das Framework bereits kennt. Sonst muss man sich dort erstmal über die ganzen Klassen und Methoden erkundigen, was mitunter viel Zeit kosten kann.

P.S.: Doppel-s nur bei Konjunktionalsätzen.

[Ganon]

Also bei mir ist es oft der Fall, dass ich gerade auf kleine Projekte oder umgesetzte Ideen erst lange Zeit später zugreifen muss oder will. Dann bin ich froh wenn ich sie a) noch habe und b) sie so geschrieben sind, dass man sie auch gut nutzen kann.

Beispiel gerade "frisch". Ich hatte zum "verstehen lernen" mal einen kleinen OR-Mapper in Java geschrieben, vor einem Jahr, oder so. Ich weiß, da gibt es zig von, aber ich wollte halt mal die Problematiken, mit denen die zu kämpfen haben, halt mal verstehen. Das sieht man ja erst, wenn man es mal selbst probiert.

Dann musste ich vor kurzem auf eine Uralt-Datenbank zugreifen. Es gab nur einen Typ-1 JDBC-Treiber der für Java 1 war (zumindest wurde Java 1.2 mitgeliefert). Der funktioniert zwar noch, aber liefert für heutige ORMs nicht genug Informationen. Da kam dann mein OR-Mapper ganz günstig, da er halt noch recht Primitiv war, aber einem trotzdem erheblich Arbeit abnahm.

Von daher ist meine Devise -> Auch kleine Projekte möglichst gut schreiben. Man weiß nie wann man sie noch brauchen kann.

[ThePsycho]

Ist eine Software gut/sinnvoll, wird sie benutzt und aus Benutzung folgern immer Verbesserungs-/Erweiterungswünsche und damit Wartung.
Das Argument, man könnte es "zu ordentlich" machen, gilt deshalb imho nicht, denn der Umkehrschluss wäre, dass niemand die Entwicklung einsetzen möchte.

Wenn dann die Aufgabenstellung mit
Diese soll Inventar verwalten
umrissen wird - das schreit ja förmlich nach OO!

[PatkIllA]

Er hat doch Recht. Die ganze Modellierungsgeschichte, die ganzen Klassen zu definieren und deren Interfaces festzulegen - das ist ein gewaltiger Mehraufwand, sehr sich später amortisiert, weil man dann relativ bequem mit den Objekten hantieren kann. Bei kleineren Projekten kann es aber sein, daß man fertig ist, bevor es sich amortisiert hat, so daß hier ein einfaches "dahinprogrammieren" schneller gewesen wäre.
Man kann auch problemlos objektorientiert was "dahinprogrammieren". Man muss ja auch nicht alles bis zum Ende ausmodellieren. Die grobe Objektstruktur und deren Zusammenhang, hat man normalerweise schon bei der Problemanalyse im Kopf. Die letzten Feinheiten entstehen dann bei der Umsetzung. Da ist bestenfalls ein kleiner Mehraufwand, denn man schon bei der ersten Anpassung wieder drin hat.

[SavageX]

Ich schließe mich da PatkIllA an.

Oftmals hat man eine ganz natürliche "dingliche" Intuition beim Nachdenken über das Problem, welche sich recht direkt in eine Objektstruktur überträgt. Für mich *persönlich* stellt sich da die Frage "OO oder nicht" gar nicht, weil ich geistige Mehrarbeit damit hätte, etwas nicht nach OO-Art zu treiben.