Regeln für OO-Programmierung

Hallo,

ich bin auf der Suche nach einer sehr generellen Sammlung an Tips, wie Softwarearchitekturen aufgebaut werden, um möglichst effizient handhabbar zu sein. Also bezogen auf Modularität z.B. was kommt an Funktionalität in eine Klasse, wann lohnt sich aus funktionaler Sicht eine Extraklasse.
Auch so eine Art problemorientierte "Best Practices" für Architekturmodelle wie MVC oder auch andere wäre gut. Außerdem wäre euch etwas über Namenskonventionen schön. Ich habe mich dazu schon beim Gnome und KDE Projekt etwas umgesehen, aber so richtig zufriedenstellend war das nicht.

Falls irgendjemand einen Link zu einer Übersicht o.ä. parat hat, wäre es super wenn er ihn hier posten könnte.
Danke

http://en.wikipedia.org/wiki/Software_design_pattern

http://en.wikipedia.org/wiki/Design_Patterns

Have fun

LVA OOPT@TUWien, sehr gut Aufgebaut, inkl. Folien und Buch (kannst downloaden), habs heuer mit einem 3er bestanden, JUHU!!! :-)
LINK OOPT

Danke für die Links.

Ich bin nicht auf der Suche nach einer Einführung in OO-Programmierung. Das wär viel zu grundlegend. Eine Übersicht und Gegenüberstellung verschiedener Architekturen wäre gut. So etwas konnte ich bisher nicht finden. So ganz auf konkrete oder allgemeine Probleme bezogen. Wann eignet sich dies, was sind Stärken von dieser Architektur, wo liegen Risiken/Schwächen...

Im FAQ hier Nützliche Links... habe ich unter dem Begriff "Antipatterns" (der ist mir bisher noch nicht unter gekommen) eine schöne Seite gefunden. Die Sichtweise auf die Risiken gefällt mir da schon sehr gut. Werde ich mir definitiv näher ansehen.

Falls du auch Literaturempfehlungen suchst, dann rate ich vor allem zu den bereits erwähnten Design Patterns und was vielleicht für dich auch interessant sein könnte wären dieses und jenes.

Folgende Bücher kann ich empfehlen: software architecture and design illuminated und Domain Driven Design

und ein Tipp: beschränke dich in deiner Sichtweise nicht auf OO. Softwarearchitekturen können mit verschiedenen Paradigmen umgesetzt werden!

An sich reicht gesunder Menschenverstand und genügend Erfahrung (und dadurch Verständnis der Denkweise).

Man kapselt sein Softwareprojekt so abstrakt wie möglich in verschiedene Packete (Klassen).
Jede Klasse sollte dabei eine Aufgabe übernehmen und durch Schnittstellen (getter und setter) die Möglichkeit haben mit anderen Objekten zu kommunizieren.

Da eine Klasse so Abstrakt wie möglich entworfen sein sollte, ergibt sich deine spezielle Aufgabe durch das Benutzen verschiedener Klassen zu einem großen.

Das ist eigentlich die Hauptdenkweise ohne Fachchinesisch.

Allerdings muss man halt wieder die Produktivität unterscheiden.
Es ist zwar wesentlich zukunftsweisender so abstrakt wie möglich zu programmieren, praktisch allerdings kaum umsetzbar bzw. kostet zuviel zeit.

Als Beispiel PHP Frameworks:
Sie sind alle auf HTML ausgesetzt. Angenommen die Browser der Zukunft benutzen jSON oder ein vollkommen neues Format als Webdokument oder ein neues Protokoll. So liese sich bei einer abstrakten Architektur das Framework um diese Funktion erweitern bzw. austauschen. Mit zusteigendem Abstraktionsgrad steigt allerdings auch der Code exponentiell an, weswegen man dann auf konkrete Implementierungen programmiert

selberbauer schrieb:

An sich reicht gesunder Menschenverstand und genügend Erfahrung (und dadurch Verständnis der Denkweise).

Man kapselt sein Softwareprojekt so abstrakt wie möglich in verschiedene Packete (Klassen).
Jede Klasse sollte dabei eine Aufgabe übernehmen und durch Schnittstellen (getter und setter) die Möglichkeit haben mit anderen Objekten zu kommunizieren.

Da eine Klasse so Abstrakt wie möglich entworfen sein sollte, ergibt sich deine spezielle Aufgabe durch das Benutzen verschiedener Klassen zu einem großen.

Das ist eigentlich die Hauptdenkweise ohne Fachchinesisch.

Allerdings muss man halt wieder die Produktivität unterscheiden.
Es ist zwar wesentlich zukunftsweisender so abstrakt wie möglich zu programmieren, praktisch allerdings kaum umsetzbar bzw. kostet zuviel zeit.

Als Beispiel PHP Frameworks:
Sie sind alle auf HTML ausgesetzt. Angenommen die Browser der Zukunft benutzen jSON oder ein vollkommen neues Format als Webdokument oder ein neues Protokoll. So liese sich bei einer abstrakten Architektur das Framework um diese Funktion erweitern bzw. austauschen. Mit zusteigendem Abstraktionsgrad steigt allerdings auch der Code exponentiell an, weswegen man dann auf konkrete Implementierungen programmiert

Zum Vergrößern anklicken....

So ein Quatsch! Klassen sind als Abstraktionselement viel zu klein. Wenn deine Architektur nur aus einem Klassendiagramm besteht, dann blickst du bei einem großen Projekt nicht mehr durch. Man sollte einen komponentenorientierten Entwurf verfolgen. D.h. Komponenten kapseln zusammengehörige Klassen (hohe Kohäsion, lose Kopplung ;-) ). Natürlich auch gegen Schnittstellen programmieren!!

Und das mit zunehmenden Abstraktionsgrad der Code exponentiell ansteigt ist auch absoluter Unsinn.

Wichtig: erst eine vernünftige Abstraktion macht Komplexität beherrschbar!

Klassen sind als Abstraktionselement viel zu klein.

Zum Vergrößern anklicken....

Was ist das für eine Aussage?

Wenn deine Architektur nur aus einem Klassendiagramm besteht, dann blickst du bei einem großen Projekt nicht mehr durch.

Zum Vergrößern anklicken....

Klassen stellen die kleinste Granularität dar!
Wie man am Ende das Projekt gestaltet, Komponentenorientiert oder Klassenorientiert ist vom Projekt und dessen Größe abhängig (=> Masstab)

Komponenten kapseln zusammengehörige Klassen

Zum Vergrößern anklicken....

Ja und weiter? Das sind Designpatterns widerspricht da dir mein Text?

Und das mit zunehmenden Abstraktionsgrad der Code exponentiell ansteigt ist auch absoluter Unsinn.

Zum Vergrößern anklicken....

Angenommen wir haben ein MVC. Dieser soll zu GTK, QT, HTML etc. kompatibel sein.
So steigt mit jeder weiter unterstützenden Schnittstelle/Biblothek die Zahl der nötigen Klassen (bsw. Adapter), um die Besonderheiten der Schnittstelle zu unterstützen.

Du stellst Antithesen auf, welche du in keinerweise argumentativ belegst und dies mit einer Spannung.

So ein Quatsch!

Zum Vergrößern anklicken....

absoluter Unsinn.

Zum Vergrößern anklicken....

Nach dem Motto: Wer am lautesten brüllt hat recht... Lächerlich

Sehr schöne Informationen, danke schon mal dafür!

Da ich in einem Projekt mit dem Grundgerüst leben muss, dass mir vorgegeben ist, hätte ich eine Frage zu Schnittstellen. Falls sich diese Aussage pauschal machen lässt: Was hat sich bei Datentypen in den Schnittstellen bezogen auf ein großes Projekt bewährt? Ist es auf längere Sicht und auch spätere Wartbarkeit nützlich alle Objektinstanzen von einer Klasse/Interface abzuleiten und diese Klasse bzw. Interface grundsätzlich in den Schnittstellen als Datentyp zu verwenden?
Als Vorteil sehe ich, dass sich so sämtliche Komponenten relativ einfach austauschen lassen. Der Entwickler muss nur wissen was wozu da ist und mit welchen Konkreten Typen er es verwenden kann.
Ich bilde mir aber auch ein, dass sich zur Laufzeit mitunter Situationen vorkommen können, in denen einem sowas auf die Füße fällt und man in einem Parameter eine Instanz hat, die im speziellen inkompatibel zur Funktion ist.

Was sind da so die Erfahrungen?

Dadurch dass du gegen ein Interface statt gegen eine konkrete Implementierung programmierst, hast du ja sozusagen immer den kleinsten gemeinsamen Nenner, den das Interface garantiert und nur darauf kannst du dich auch in anderen Klassen, die auf ein Objekt zugreifen (welches dieses Interface implementiert), auch verlassen.

Das ist übrigens auch einer der ersten Punkte in dem Design Patterns Buch, was ich vorgeschlagen habe. Wenn du dann irgendwo in den Implementierungen wissen musst, welche konkrete Implementierung eines Interfaces vorliegt, dann gibt es immer noch RTTI und entsprechendes casten, damit du an die erweiterte Funktionalität rankommst.

Wie gesagt, dadurch dass man sich immer auf den kleinsten gemeinsamen Nenner beschränkt, ist eben diese Austauschbarkeit gewährt.

Okay soweit. Bekannt ist mir das alles schon, ich wollt nur wissen ob es auch gängige Praxis ist, dass man sagen wir mal 40 Klassen über 1 Interface jagt. Theorie und Praxis gehn ja immer gern ein wenig auseinander

Okay soweit. Bekannt ist mir das alles schon, ich wollt nur wissen ob es auch gängige Praxis ist, dass man sagen wir mal 40 Klassen über 1 Interface jagt. Theorie und Praxis gehn ja immer gern ein wenig auseinander

Zum Vergrößern anklicken....

Das kommt auf die Situation an. Willst du bsw. die Konfigurationsparameter über ver. Typen einlesen lassen, dann kann es schon vorkommen das eine zweistellige Klassenanzahl über ein Interface läuft.
Dann hat man die zig Klassen für yaml, xml, ini, csv, sql,..., welche das Dokument bzw. das Format parsen und ein array zurückliefern und array zurückliefern bzw. die Methoden zur initalisierung des parsens laufen dann über die Schnittstelle.

Mit der Zeit hat man sein eigenes Interface im Kopf und man hat sich eine Schreibweise angewöhnt, welche die Schnittstellen oder allgemein Methoden einfach zu ordnen lässt.
Bsw.:
findAllByName
getName
setName
...

selberbauer schrieb:

Was ist das für eine Aussage?

Klassen stellen die kleinste Granularität dar!
Wie man am Ende das Projekt gestaltet, Komponentenorientiert oder Klassenorientiert ist vom Projekt und dessen Größe abhängig (=> Masstab)

Ja und weiter? Das sind Designpatterns widerspricht da dir mein Text?

Zum Vergrößern anklicken....

Was ist an der Aussage, dass Klassen das kleinste Abstraktionselement sind, so schwierig zu verstehen? Das schreibst du im nächsten Satz ja selbst, dass diese die kleinste Granularität darstellen. Und ein Klassendiagramm ist nun mal zu unübersichtlich und komplex, um eine Architektur darzustellen.

Und Komponentenorientierung ist kein Design-Pattern, sondern ein Paradigma. Ob du in deiner Komponente nun objektorientiert oder funktional programmierst, ist vollkommen latex. Es ist lediglich ein Abstraktionsmittel, welches vom Abstraktionsgrad quasi eine Stufe höher ist, als OOP.

Architekturen sind oft schon sehr abstrakt. Viel abstrakter als zb patterns. Ich würde erstmal nach einigen Architekturstielen googeln, die man so kennt. was mir spontan einfällt:

pipes and filters
client / server architecture
peer-to-peer architecture
cloud architecture
call return style
event driven systems
component connector style
Layered architecture
Service oriented architectures

Im Allgemeinen würde ich sagen das am Anfang patterns lernen relativ wenig bringt.
In meinen Augen macht es nur Sinn sich zuerst einmal darauf konzentriert wie man Code richtig strukturiert keine langen Methoden schreibt, wenn sinnvoll (was oft ist) Code in neue Klasse auslagert.
Wenn man das anständig macht verwendet man einige patterns automatisch ohne es zu wissen. Dadurch kommt dann wenn man sich mit Patterns beschäftigt der aha effekt und man kann die manchmal etwas abstrakt klingenden Patterns viel besser in die Realität mappen.

Für den Anfang sollte man einmal das 3 Layer Model verinnerlichen damit verbunden was ist ein thin / thick client. Dann weiter gehen zu Client - Server Modeln da einfach mal etwas rumporbieren etwas Googlen. Einfach einen kleinen Chat oder etwas derartiges Programmieren. Eines gilt auf alle fälle vom Patterns bücher lernen ist noch niemand ein guter Programmierer / Architekt geworden. Das formale wissen über Patterns wird erst interessant wenn man wirkliche Architekturen plant.

Zusammenfassung: Überforder dich nicht mit dem lernen von Patterns sondern konzentrier dich aufs Programmieren dann kommen die Patterns von allein. Erst wenn du die standard dinger drauf hast kann man sich explizit mit Patterns auseinandersetzen. Wenn du irgendwelche fragen zu den zwei von mir erwähnten dinge hast kann man mich in der Regel auch per PM fragen.