OOP Verständnisproblem Umsteiger

[sorbas]

Hallo Zusammen,

aus der proceduralen Welt kommend (Pascal, Cobol, C), habe ich da noch ein "kleines" Verständnisproblem mit der OOP bzw. Java:

Also, ich habe die OOP so verstanden, dass einzelne Aufgaben in einzelnen Klassen gekapselt werden sollen und diese ihre Ergebnisse an die nächste Klasse weiterreichen.

Nun soll ich eine Datei einlesen, diese Satz für Satz bearbeiten und wieder auf eine neue Datei ausgeben, dabei soll der Headersatz der neuen Datei Infos aus mehreren Sätzen der alten Datei enthalten.
Gemäss meines Verständnisses der OOP würde ich nun die Klasse Datei_lesen erstellen, welche die Input-Datei Satz für Satz einliest und in ein Array schiebt.
Nur, wie komme ich nun mit der nächsten Klasse, welche das Array verarbeiten soll, an die Werte des Arrays?

Globale Variablen? Mit Tricks möglich, aber verpönt.
Alle Felder der Input-Datei/des Arrays in die Klassen-Aufrufe reinschreiben? Zuviele.
Statt eines Arrays eine Datei erzeugen, möglich aber umständlich.

An dieser Stelle verstehe ich den OOP Ansatz einfach nicht. Vielleicht kann mir jemand hier das Brett vorm Kopf wegzimmern???

Gruss

Sorbas

 

[SlaterB]

ein Array ist eine einzelne Variable, was ist da zuviel?
das Array kann per Methodenaufruf an die nächste Klasse übergeben werden oder die zweite Klasse fragt sie bei der ersten ab

 

[Andgalf]

Hmm ich versuchs mal

Wenn Du eine Klass DateiLesen hast, erstellst Du in dieser eine Methode welche Dir ein enstprechendes Array zurückgibt.
etwa so

public String[] leseDatei(String pfadZurDatei){

// Datei einlesen 
// Array erstellen
return fertigesArray
}

diese Kannst Du dann aus einem anderen Objekt aufrufen
etwa so

DateiLesen dateiLesen = new DateiLesen();
String[] ergebnisArray = dateiLesen.leseDatei("pfadZurDatei");

 

[JanHH]

Nee, das hast Du falsch verstanden, das kann man so nicht sagen.

Bei OO handelt es sich eher um den Ansatz, die Anwendung gemäß ihrer Strukur in Objekte aufzuteilen, die sinnvolle Funktions- und Dateneinheiten darstellen. Vorbild ist die reale Welt, wo das genauso ist. Ein Telefon ist ein Telefon und stellt verschiedene Funktionen bereit, und derjenige, ders benutzt, muss nur diese Funktionen kennen, und nicht wissen wie die intern implementiert sind, und auch nicht wissen, welche Klasse der Telefon-Klassenhierarchie (Telefon -> Festnetztelefon -> Tastentelefon/Wählscheibentelefon, bzw -> Mobiltelefon -> klassisches Handy/Smartphone) er da vor sich hat, um zu telefonieren. So ist das in etwa ;-).

Allerdings wird auch in objektorientierten Systemen auf irgendwelchen Ebenen prozedural gearbeitet, geht ja auch nicht anders, irgendwo müsen die Algorithmen ja auch konkret implementiert sein. So ein Fall liegt bei Dir vor. Um das objektorientiert zu kapseln könntest Du z.B. eine Klasse schreiben, die den Inhalt der ersten Datei als Dokument repräsentiert, und diese mit zwei Funktionen ausstatten.. "readFromOldFile" und "writeToNewFile". Innerhalb dieser Funktionen wird natürlich eher prozedural gearbeitet. Der Inhalt der Datei wird irgendwie intern in der Dokument-Klasse gespeichert.

 

[Gregorrr]

Methoden sind die Schnittstellen einer Klasse nach außen. Sie dienen der kontrollierten Ein- und Ausgabeverwaltung.

Getter-Methoden liefern etwas, während Setter-Methoden den Zustand eines Objekts (einer Instanz einer Klasse, also de-facto Klasse) verändern können. Dies ist, damit es kontrollierte Wege der Verarbeitung gibt. In der Methode wird bestimmt, wie und was nach Außen gelangen darf und was nicht, bzw. wie etwas verändert werden kann und wie nicht. Dabei kann es auch ganz einfache Getter geben, die einfach nur einen Wert zurückliefern, ohne diesen besonders vorher zu bearbeiten.

Was musst du genau ausgeben? Nur die Header-Zeile? Dann bietet es sich z.B. eine public String getHeader() an, die kannst du dann einfach aus der anderen Klasse benutzten, ist ja public.

Willst du das ganze Array ausgeben, bietet sich vielleicht: public String[] getSentences() an.

Am ehesten OOP, wäre eventuell ein Iterator:
Kennst du das Konzept des Iterators? Eventuell würde sich ein Iterator anbieten, der den Zustand des String[] zu einem bestimmten Zeitpunkt kapselt.

Coding-Conventions:
Nach Coding-Conventions würdest du die Klasse: DateiLesen nennen (vielleicht zu allgemein), oder noch besser, den genauen Zweck in dem Namen angeben, da gibt es sicherlich viele Möglichkeiten, aber in Java sollte man eher keine _ verwenden sondern sog. CamelCase.

 

[sorbas]

Hallo SlaterB,
hallo Andgalf,

Ihr seid die besten "Zimmerleute", die ich kenne! Danke :toll:

Manchmal bin ich einfach zu blöd, natürlich bildet ein Array genau wie jede Datei nur den Container und lässt sich damit auch von Methode zu Methode durchreichen. Nur drauf kommen muss man

Gruss

Sorbas

 

[sorbas]

Hallo JanHH,

danke für den Hinweis.

... irgendwelchen Ebenen prozedural gearbeitet...

D.h., in den Ebenen, wo ich meist unterwegs bin, Daten schaufeln, DB-Abfragen zur Weiterverarbeitung etc. wird sich für mich OOP garnicht so sehr bemerkbar machen??

Gruss

Sorbas

 

[sorbas]

Hallo Gregorrr,

danke für die Hinweise.

Was musst du genau ausgeben? Nur die Header-Zeile?

Leider nein, die ganze Input Datei muss umgeschaufelt werden und dabei müssen bestimmte Feldinhalte, die irgendwo in der Inputdatei stehen, abgefischt und in die Header-Zeile der Output-Datei geschrieben werden.
Deshalb auch das Array, da kann ich vor der Ausgabe auf jede Zeile zugreifen und sie ggf. ergänzen.

Gruss

Sobras

 

[Gregorrr]

Hallo JanHH,

danke für den Hinweis.

D.h., in den Ebenen, wo ich meist unterwegs bin, Daten schaufeln, DB-Abfragen zur Weiterverarbeitung etc. wird sich für mich OOP garnicht so sehr bemerkbar machen??

Gruss

Sorbas

Nee, gar nicht. Man kann in C z.B. auch Objekt-orientiert arbeiten, allerdings nicht so flexibel wie in einer "echten" Objekt-orientierten Sprache. Genauso kann man z.B. in Java auch prozedural entwickeln, wenn man z.B. alles nur mit statischen Methoden und mit direkten Zugriffen auf Felder arbeitet (nicht zu empfehlen, man sollte schon die Art und Weise auch einhalten, für die eine Sprache entwickelt wurde).

Übrigens kommt es dadurch schon "zwanghaft" zu Redundanzen, da manchmal zwei Klassen ähnliche Verantwortlichkeiten/Funktionalität bieten und es sich z.B. nicht lohnen würde eine extra Klasse für z.B. nur eine Methode zu verwenden. Da kommt es immer auf die Verhältnismäßigkeit an.

Ein weiterer Schritt, falls du OOP mal verinnerlicht hast und es gut anwenden kannst, wäre es sich mit Design Patterns zu beschäften, diese sind für die OOP öfters verwendete Design Muster, die einfach ab und zu wiederkehren. Das aber nur, falls man wirklich größere Programme macht.

 

[JanHH]

Ich würde sagen, jein.. die zugrundelegenden Algorithmen sind natürlich die gleichen wie ohne OOP, aber man sollte das ganze schon verstanden haben. Aber SQL bleibt SQL und Quicksort bleibt Quicksort. Kann man irgendwie schwer pauschal beanworten. Es gibt halt eine richtige Art, zu programmieren, und viele falsche. Wenn mans einmal verstanden hat, hat das auf fast alle Bereiche des Programmierens Einfluss. Wobei es eh mehr mit "Software-Design" zu tun hat als mit Programmieren an sich. Aber das ist auch eine Sache der Übung und Erfahrung. Wer OOP lernen will soll mal Smalltalk lernen (die Programmierprache), gute Übung.

 

[Landei]

Ein typischer Umsteiger-Fehler ist, Prozesse als Klassen abzubilden. Klassen sollten aber typischerweise "Substantive" (Kunde, Dialog, Liste, String, ...) sein, nicht "Verben" (aber etwas "XyzManager" oder "BlaProcessor" zu nennen, ist gemogelt und macht das Ganze auch nicht besser).

Man sollte sich am Single-Responsibility-Prinzip orientieren, sowohl für Methoden wie auch für Klassen. Alles sollte genau eine Aufgabe erfüllen (und diese gut). Ein guter Tipp dazu von Onkel Bob: Es sollte nur einen einzigen Umstand geben, der eine Änderung einer Klasse (oder Methode) nach sich zieht. Ein Prozess fällt bei diesem Test durch: Sowohl das Lesen wie auch das Verarbeiten oder das Schreiben der Daten könnte sich ändern, und eine entsprechende Klasse müsste ebenfalls geändert werden.

 

[tfa]

in typischer Umsteiger-Fehler ist, Prozesse als Klassen abzubilden. Klassen sollten aber typischerweise "Substantive" (Kunde, Dialog, Liste, String, ...) sein, nicht "Verben"

Nur nicht so vorschnell. Klassen, die Dinge tun, können auch so heißen, also ein Verb als Namen haben.

Ich habe vor kurzem einen (interaktiven) Vortrag von "Clean Code Developer" Ralf Westphal gehört, in dem er dem Publikum diese Vorstellung "Klassenname = Substantiv" auszutreiben versuchte - das war nicht so einfach.
Leider habe ich hierzu nichts im Netz gefunden- nur diesen kostenpflichtigen Artikel:

Wer Software in objektorientierterWeise entwirft, beginnt die Analyse von Anforderungen meist mit der Suche nach Substantiven. Daraus werden Klassen, die bekommen Eigenschaften und auf die wird Funktionalität verteilt. Dabei ist Software viel näher am Tun: Die Zukunft gehört den Verben.

Wie gesagt, ich kenn nur den Vortrag, nicht den Artikel.

 

[Gregorrr]

Nur nicht so vorschnell. Klassen, die Dinge tun, können auch so heißen, also ein Verb als Namen haben.[/URL]:

Wie gesagt, ich kenn nur den Vortrag, nicht den Artikel.

So sieht es aus. Vor allem, weil Verben auch Substantive sind: das Gehen, das Schreiben, das Übertragen, usw.

Was wird denn im Strategy Pattern, oder Command Pattern abgekapselt und als Klasse implementiert? Befehle, Strategien, als Verhalten, die etwas kapseln.

Nicht zu vergessen, dass andere Sprachen durch funktionale Bestandteile es elaganter ausdrücken können. Aber soweit ich weiß sind in Scala named Functions auch Bestandteil einer Klasse... ?

---

Bei uns in der Hochschule war auch einer von Clean Code da - mir sieht es eher so aus, als würden die Leute mit dem Trend eher Geld machen wollen... Totales Halbwissen und auf keine Diskussion eingelassen... Ich mag Clean Code gar keine Frage, aber bei einigen Sachen muss man vieles in Relation sehen.

 

[maki]

Bei uns in der Hochschule war auch einer von Clean Code da

Für mich sind die jungs von der ""Clean code Developer Initiative" Trittbrettfahrer die auch zugeben nicht wirklich so viel mit dem Buch "Clean Code" von Bob Martin zu tun haben (und das Buch ist imho eines der besten zu diesem Thema).

hier mal ein etwas radikaler Artikel, da wird u.a. der Tipp gegeben "Don't make objects that end with 'er'."

Objology: One of the Best Bits of Programming Advice I ever Got

Ist wie gesagt sehr radikal, kann man nicht 100% umsetzen, aber bevor man sich eine Armada an "Manager" etc. Klassen schreibt sollte man zumindets die Nachteile verstehen.

 

[ralf.westphal]

@maki: Aha, die Jungs von der Clean Code Developer Initiative sind Trittbrettfahrer? Schade, dass du auch noch als Moderator hier ein solch pauschales Urteil aussprichst. Wie ist denn deine Definition von Trittbrettfahrer? Ist Bob Martin auch Trittbrettfahrer, weil er die Objektorientierung nicht erfunden hat? Oder zumindest James Gosling?

Clean Code Developer (CCD, http://www.clean-code-developer.de]Clean Code Developer - Clean Code Developer) ist eine Sammlung von Prinzipien und Praktiken. Natürlich haben Stefan Lieser und ich die nicht erfunden (bis auf vielleicht zwei). Genausowenig haben Gamma et al. die Entwurfsmuster erfunden. Auch die müssten nach deiner Definition Trittbrettfahrer sein.

Die Leistung von CCD liegt nicht darin, etwas erfunden zu haben. (Das haben wir ja auch nie behauptet.) Sie liegt im Zusammentragen, Organisieren und Veröffentlichen von schon vorher Existentem. Nicht mehr und nicht weniger haben wir geleistet. Daraus ist dann eine eigene sichtbare Diskussion über innere Softwarequalität entstanden. Das XING-Forum zum Thema CCD hat 2600+ Mitglieder. Da geht es dann nicht um technisches Klein-Klein, sondern um Grundsätzlicheres.

Ich würde mich freuen, wenn du CCD etwas differenzierter sehen könntest. Wenn du Fragen hast, melde dich gern.

@Landei: Was du als typischen Umsteigerfehler bezeichnest, ist nur ein typischer Umsteigerfehler im Hinblick auf eine bestimmte Ausprägung der Objektorientierung. Ich sage mal platt die OOA/D und typische UML Variante der OO. Mit deiner Aussage befindest du dich in jedem Fall im Konzeptionellen.

Auf der anderen Seite ist die technische Seite. Die betrifft konkrete Mittel wie Klassen, Vererbung, Polymorphie usw.

Die Ausgangsfrage von @sorbas bezieht sich, würde ich sagen, auf die konzeptionelle OO. Denn die leitet die Nutzung der technischen OO-Mittel an.

Wenn ich aber nun beide getrennt sehe - konzeptionelle und technische OO -, dann kann ich mir auch vorstellen, dass die technische OO nicht von der konzeptionellen OO geleitet wird.

Ich könnte technische OO Mittel auch aus Sicht der FP oder LP nutzen. Und warum nicht? Am Ende zählt doch nur eines: Erfüllt der resultierende Code die funktionalen wie nicht-funktionalen Anforderungen und ist er fehlerfrei wie evolvierbar.

Die konzeptionelle OO hat - wie man landauf-landab sehen kann - offensichtlich nicht fehlerfreiem und evolvierbarem Code geführt. Seit 20 Jahren verspricht sie das aber den "Entwicklermassen". Auch Entwurfsmuster und UML haben es nicht hinbekommen. Projekte stehen bis zur Hüfte in Unwartbarkeit. Selbst ohne eine Vorstellung davon, wie es anders gehen könnte, sollte daher klar sein, dass es so nicht weitergehen kann. Auch Clean Code ist da nur eine Symptomkur. Das merkt jeder, der bei einem Refaktorisierungsmarathon nach Namen sucht für die immer kleiner werdenden Klassen; denn zu nichts anderem führen Prinzipien wie SRP, SoC, SLA oder KISS. Soviele Managers, Controllers, Coordinators kann es gar nicht in einem Softwaresystem geben... Aber wie dann solche Klassen bezeichnen?

Vielleicht kommt die Lösung ja aus unerwarteter Richtung. Vielleicht muss man einfach mal aufhören, mehr vom Selben zu versuchen (nämlich Zustand und Funktionalität unter Substantiven zusammenzufassen). Vielleicht wird dann alles einfacher.

-Ralf Westphal
ralfw.blogspot.com
@ralfw

 

[maki]

@maki: Aha, die Jungs von der Clean Code Developer Initiative sind Trittbrettfahrer? Schade, dass du auch noch als Moderator hier ein solch pauschales Urteil aussprichst. Wie ist denn deine Definition von Trittbrettfahrer? Ist Bob Martin auch Trittbrettfahrer, weil er die Objektorientierung nicht erfunden hat? Oder zumindest James Gosling?

Clean Code Developer (CCD, http://www.clean-code-developer.de]Clean Code Developer - Clean Code Developer) ist eine Sammlung von Prinzipien und Praktiken. Natürlich haben Stefan Lieser und ich die nicht erfunden (bis auf vielleicht zwei). Genausowenig haben Gamma et al. die Entwurfsmuster erfunden. Auch die müssten nach deiner Definition Trittbrettfahrer sein.

Die Leistung von CCD liegt nicht darin, etwas erfunden zu haben. (Das haben wir ja auch nie behauptet.) Sie liegt im Zusammentragen, Organisieren und Veröffentlichen von schon vorher Existentem. Nicht mehr und nicht weniger haben wir geleistet. Daraus ist dann eine eigene sichtbare Diskussion über innere Softwarequalität entstanden. Das XING-Forum zum Thema CCD hat 2600+ Mitglieder. Da geht es dann nicht um technisches Klein-Klein, sondern um Grundsätzlicheres.

Ich würde mich freuen, wenn du CCD etwas differenzierter sehen könntest. Wenn du Fragen hast, melde dich gern.

Hi,

für mich sieht es so aus als ob die "Clean Code Developer Initiative" Interesse daran hat Geld zu verdienen, was verständlich, nachvollziehbar und auch völlig i.O. ist.
Der Begriff "Trittbrettfahrer" mag sich im ersten moment hart anhören, war aber vor allem auf "Clean Code" bezogen, sorry, da hättet ihr auch ruhig kreativ werden können anstatt euch einfach von der Welle der Erfolges dieses Buches mittragen zu lassen.

Die Prinzipien sind schon seit Jahren bekannt, da ist nicht viel neues dabei (falls überhaupt), aber durch eine 1 wöchige Schulung bringt man niemandem TDD bei, durch Armbänder fangen Leute nicht plötzlich an sich zu kümmern.
Leute die sich kümmern kennen die Prinzipien bereits, sind ja nicht geheim o.ä.
Leute die sich nicht kümmern wird man nicht in einem Kurs vermitteln können warum sie sich plötzlich für ihre Arbeit interessieren sollten.

Nebenbei, Entwurfsmuster werden per Definition nicht "erfunden" sondern immer nur "gefunden", der Vergleich hinkt.

Die konzeptionelle OO hat - wie man landauf-landab sehen kann - offensichtlich nicht fehlerfreiem und evolvierbarem Code geführt. Seit 20 Jahren verspricht sie das aber den "Entwicklermassen". Auch Entwurfsmuster und UML haben es nicht hinbekommen. Projekte stehen bis zur Hüfte in Unwartbarkeit. Selbst ohne eine Vorstellung davon, wie es anders gehen könnte, sollte daher klar sein, dass es so nicht weitergehen kann. Auch Clean Code ist da nur eine Symptomkur. Das merkt jeder, der bei einem Refaktorisierungsmarathon nach Namen sucht für die immer kleiner werdenden Klassen; denn zu nichts anderem führen Prinzipien wie SRP, SoC, SLA oder KISS. Soviele Managers, Controllers, Coordinators kann es gar nicht in einem Softwaresystem geben... Aber wie dann solche Klassen bezeichnen?

Auch wenn das nicht an mich gerichtet war...
Empfehle da DDD von Eric Evan
Da gibt es dann keine Controller/Manager mehr, auch keine "dummen" Datentypen ohne Logik und Namen aus der eigentlichen Problemdomäne sind wieder sehr wichtig.
Begriffe wie "Manager"/"Controller" deuten schon eben sehr stark darauf hin dass Logik & Daten getrennt sind und es sich um ein Prozedurales Design handelt, wurde ja auch lange genug von div. Firmen als "Best Practise" dargestellt (Suns J(2)EE Pattern Katalog zB.), die Effekte die daraus resultieren sind eben nicht die Effekte von OOP, refactoring endet nicht zangsweise mit Controllern/Managern.

 

[ralf.westphal]

@maki: Ist Tritttbrettfahrertum dann, wenn irgendwer irgendetwas sagt, was schon andere gesagt haben? Wohl kaum. Sonst bräuchten wir eher nur 1 Buch, 1 Vortrag, 1 Training zu Scrum, OOP, Kanban, JBoss usw.

Ist Trittbrettfahrertum, wenn wir die Initiative "Clean Code Developer" nennen, weil es ein Buch "Clean Code" gibt? Dann wäre ja "Applying Domain Driven Design" von Jimmy Nilsson auch ein Trittbrettfahrerbuch wie jedes Buch das nach dem Buch "XXX" heißt wie "XXX Explained" oder "YYY in-depth" usw.

Aber abgesehen von solchen formalen Kleinigkeiten scheinst du nicht gut mit der Initiative vertraut zu sein. Denn dann wüsstest du, dass erstens das Feedback häufig und deutlich gewesen ist, dass CCD den Entwicklern etwas bringt, was das Buch CC ihnen nicht gebracht hat. Und zweitens wäre dir geläufig, dass CCD eben nicht CC abgeschrieben, sondern gefiltert hat und auch noch andere Quellen eingegangen sind. Und drittens dürfte dir klar sein, dass es nicht darauf ankommt, ob irgendetwas schon mal irgendeiner gesagt hat, sondern darauf, dass es zum rechten Zeitpunkt einer in "verdaubarer" Weise sagt.

Wer darauf rumreitet, "Das hat ja X schon vor 20 Jahren gesagt", der muss auch die Frage beantworten, warum es offensichtlich nichts genutzt hat, dass X etwas schon vor 20 Jahren gesagt hat, da doch offensichtlich niemand X bzw. seine Aussage kennt oder berücksichtigt.

Bottom line: Es ist mindestens wenig hilfreich, trollige Urteile wie "Trittbrettfahrertum" im Vorbeigehen abzulassen. Wenn du nicht vertraut bist mit der Effektivität und Effizienz einer CCD Schulung oder von "Spielkram" wie CCD Armbändern, dann enthalte dich doch pauschaler Aussagen - bis du ein fundierteres Urteil fällen kannst oder Leute gehört hast, die das getan haben, worüber du urteilst.

Zu den Entwurfsmustern: Entwurfsmuster werden natürlich erfunden. Es gibt einen, der etwas zum ersten Mal tut. Das läuft für ihn gut. Dann machen es andere nach. So entsteht ein Muster durch Wiederholung. Und schließlich gibt einer dem einen Namen.

Die Erfindung ist nur nicht geplant. Sie zieht sich hin. Bis Muster entstehen, braucht es Zeit. Aber unzweifelhaft tut es jemand zuerst und dann verbreitet es sich, weil es gut funktioniert. Dass man vielleicht nicht weiß, wer es war, tut dem keinen Abbruch.

Zu Leuten, die sich kümmern: Mein Gefühl ist, dass du nicht recht weißt, was Leute, die sich kümmern, alles nicht wissen. Definiere überhaupt "kümmern" mal. Wer hier nicht im Forum ist, kümmert sich nicht? Wer nicht zu einer UG geht, kümmert sich nicht? Wer DDD nicht gelesen hat, kümmert sich nicht? Bestimmt kümmerst du dich - aber mit einem Moment Geduld finden wir bestimmt das eine oder andere Thema, das jemand, der sich auch kümmert für wichtig hält, von dem du aber keine Ahnung hast. Ich wäre als vorsichtig, Leute, die im Projekt noch keinen Bounded Context identifiziert haben, als Nicht-Kümmerer abzustempeln.

Zu DDD: Eric Evans hat es selbst gesagt, aber jeder, der das Buch ganz gelesen hat - und nicht nur die erste Hälfte -, der weiß es auch selbst: der Teil über Entitäten, Value Objects usw. ist der schwächste des Buches.

Und dass eine Trennung von Logik und Daten schon gleich "prozedurales Design" ist, das erzähle doch einfach mal den Leuten aus der FP-Ecke.

Und was sind denn die "Effekte von OOP"? Wo sind die Erfolgsstories der letzten 20 Jahre? Klar, ich möchte technische OO nicht missen. C# ist eine coole Sprache. Aber die beschworenen Effekte der OOP - Wiederverwendbarkeit, Wartbarkeit, Einfachheit der Entwicklung - sehe ich leide so gar nicht. Mache selbst den Test:

Nimm eine der Aufgaben auf dieser Seite: Application Katas Clean Code Advisors
Gehe in eine User Group deiner Wahl, bilde aus den Anwesenden kleine Entwicklerteams von 3-5 Leuten.
Gib ihnen nur die 1. Iteration einer der Application Katas und lass sie 90 Minuten daran entwickeln und abliefern.
Kommen lauffähige Lösungen heraus? Wieviele Anforderungen wurden umgesetzt? Haben die Teams daran als Team gearbeitet?
Und dann die 2. Iteration.
Dann die 3. Iteration.
usw.

Schau dir an, was da in jeweils 90 Minuten passiert. Wie schlägt sich die OOP?
Ich bin gespannt.

 

[maki]

@maki: Ist Tritttbrettfahrertum dann, wenn irgendwer irgendetwas sagt, was schon andere gesagt haben? Wohl kaum. Sonst bräuchten wir eher nur 1 Buch, 1 Vortrag, 1 Training zu Scrum, OOP, Kanban, JBoss usw.

Ist Trittbrettfahrertum, wenn wir die Initiative "Clean Code Developer" nennen, weil es ein Buch "Clean Code" gibt? Dann wäre ja "Applying Domain Driven Design" von Jimmy Nilsson auch ein Trittbrettfahrerbuch wie jedes Buch das nach dem Buch "XXX" heißt wie "XXX Explained" oder "YYY in-depth" usw.

Aber abgesehen von solchen formalen Kleinigkeiten scheinst du nicht gut mit der Initiative vertraut zu sein. Denn dann wüsstest du, dass erstens das Feedback häufig und deutlich gewesen ist, dass CCD den Entwicklern etwas bringt, was das Buch CC ihnen nicht gebracht hat. Und zweitens wäre dir geläufig, dass CCD eben nicht CC abgeschrieben, sondern gefiltert hat und auch noch andere Quellen eingegangen sind. Und drittens dürfte dir klar sein, dass es nicht darauf ankommt, ob irgendetwas schon mal irgendeiner gesagt hat, sondern darauf, dass es zum rechten Zeitpunkt einer in "verdaubarer" Weise sagt.

Vielleicht liegt es auch daran, dass ihr einerseits den Namen des Buches verwendet, andererseits aber Dinge abändert/interpretiert/hinzufügt, kurz: Ihr nennt es Clean Code Initiative, verkauft aber etwas anderes, ähnlich ja, aber eben doch etwas anderes.

Wer darauf rumreitet, "Das hat ja X schon vor 20 Jahren gesagt", der muss auch die Frage beantworten, warum es offensichtlich nichts genutzt hat, dass X etwas schon vor 20 Jahren gesagt hat, da doch offensichtlich niemand X bzw. seine Aussage kennt oder berücksichtigt.

Hier sollte keiner auf irgendetwas rumreiten, der Punkt ist:
Es sind bekannte Sachen.
Wenn ihr diese Konzepte, Vorgehensweisen und innere Einstellungen vermittelt und die "Schüler" zufrieden sind: Super, ist doch alles in Ordnung.

Bottom line: Es ist mindestens wenig hilfreich, trollige Urteile wie "Trittbrettfahrertum" im Vorbeigehen abzulassen. Wenn du nicht vertraut bist mit der Effektivität und Effizienz einer CCD Schulung oder von "Spielkram" wie CCD Armbändern, dann enthalte dich doch pauschaler Aussagen - bis du ein fundierteres Urteil fällen kannst oder Leute gehört hast, die das getan haben, worüber du urteilst.

"Spielkram" ist ein Wort dass ich nicht benutzt habe.
Wer unterstellt jetzt wem etwas?

Zu den Entwurfsmustern: Entwurfsmuster werden natürlich erfunden. Es gibt einen, der etwas zum ersten Mal tut. Das läuft für ihn gut. Dann machen es andere nach. So entsteht ein Muster durch Wiederholung. Und schließlich gibt einer dem einen Namen.

Die Erfindung ist nur nicht geplant. Sie zieht sich hin. Bis Muster entstehen, braucht es Zeit. Aber unzweifelhaft tut es jemand zuerst und dann verbreitet es sich, weil es gut funktioniert. Dass man vielleicht nicht weiß, wer es war, tut dem keinen Abbruch.

Durch Wiederholung wird es nicht richtig.
Entwurfsmuster werden erkannt, nicht erfunden, ein Entwurfsmuster ist erst dann ein Entwurfsmuster wenn es mehrmals in unterschiedlichen Sprachen/Kontexten eingesetzt wird und einen gewissen Abstraktionsgrad hat.
Die Lösung eines konkreten Problems stellt nur eine konkrete Lösung dar, wer zum ersten mal sowas macht erfindet eben kein Entwurfsmuster, sondern eine konkrete Lösung.

Die GoF hat ja wiederholende Muster gesucht/gesammelt.

Zu Leuten, die sich kümmern: Mein Gefühl ist, dass du nicht recht weißt, was Leute, die sich kümmern, alles nicht wissen. Definiere überhaupt "kümmern" mal. Wer hier nicht im Forum ist, kümmert sich nicht? Wer nicht zu einer UG geht, kümmert sich nicht? Wer DDD nicht gelesen hat, kümmert sich nicht? Bestimmt kümmerst du dich - aber mit einem Moment Geduld finden wir bestimmt das eine oder andere Thema, das jemand, der sich auch kümmert für wichtig hält, von dem du aber keine Ahnung hast. Ich wäre als vorsichtig, Leute, die im Projekt noch keinen Bounded Context identifiziert haben, als Nicht-Kümmerer abzustempeln.

Ich wäre vorsichtig Leuten Aussagen zu unterstellen die sie nie gemacht haben, zeugt nicht gerade von der Fähigkeit über gesagte Dinge argumentieren zu können.
Man muss nicht DDD gelesen haben weil man sich kümmert, man muss auch nicht alles der einschlägigen Literatur gelesen haben wenn man sich kümmert.
Aber irgendetwas davon wird jemand, der Interesse an seinem Beruf als SW Entwickler hat, schon lesen werden, und auch versuchen anzuwenden, denn nur vom lesen wird man nicht besser.

Zu DDD: Eric Evans hat es selbst gesagt, aber jeder, der das Buch ganz gelesen hat - und nicht nur die erste Hälfte -, der weiß es auch selbst: der Teil über Entitäten, Value Objects usw. ist der schwächste des Buches.

Ach wirklich?
Dann bin ich mal auf ein Zitat gespannt, schliesslich meine ich dass "der Teil über Entitäten, Value Objects usw." zum Kern von DDD gehört.

Und dass eine Trennung von Logik und Daten schon gleich "prozedurales Design" ist, das erzähle doch einfach mal den Leuten aus der FP-Ecke.

Bei der Objektorientierung geht es eben u.a. darum, dass Operationen und Daten die zusammengehören auch zusammen sind.
Aber was hat das mit funktionalen Programmiersprachen zu tun??

Klassische Beispiele für für prozedurales Design das einer OO Sprache übergestülpt wird ist eben EJB 2.x und EJB 3.x in denen die "Entitäten" nur "dumme" JavaBeans sind und die interessante Logik in SessionBeans gesteckt wird.
JavaBeans sind keine Objekte im Sinne der OO sondern nur "Datenstrukturen" mit spez. Zugriff.

Und was sind denn die "Effekte von OOP"? Wo sind die Erfolgsstories der letzten 20 Jahre? Klar, ich möchte technische OO nicht missen. C# ist eine coole Sprache. Aber die beschworenen Effekte der OOP - Wiederverwendbarkeit, Wartbarkeit, Einfachheit der Entwicklung - sehe ich leide so gar nicht.

Hmm... nur soviel dazu:
Mein Friseur hat auch keine Glatze... solltest schon ein bisschen an das Glauben worum es geht, oder etwa nicht?

Sicherlich ist OO kein "Silver Bullet" für jedes Problem in jeder Lage, aber zu behaupten dass etwas nicht funktioniert kann 2 Ursachen haben:
1. Dieses "etwas" funktioniert wirklich nicht
2. Es liegt an einem selber

Wenn man beim refactoren immer wieder mit Manager/Controller endet liegt es nicht am Refactoring selber, sondern daran wie man selber denkt.
Schon mal gesehen das Fowler immer mit Controllern/Managern endet?
Nein? Woran das wohl liegt...

Nimm eine der Aufgaben auf dieser Seite: Application Katas Clean Code Advisors
Gehe in eine User Group deiner Wahl, bilde aus den Anwesenden kleine Entwicklerteams von 3-5 Leuten.
Gib ihnen nur die 1. Iteration einer der Application Katas und lass sie 90 Minuten daran entwickeln und abliefern.
Kommen lauffähige Lösungen heraus? Wieviele Anforderungen wurden umgesetzt? Haben die Teams daran als Team gearbeitet?
Und dann die 2. Iteration.
Dann die 3. Iteration.
usw.

Schau dir an, was da in jeweils 90 Minuten passiert. Wie schlägt sich die OOP?
Ich bin gespannt.

Übungsaufgaben geschrieben von jemandem der nicht an OO glaubt würden was genau beweisen?

 

[ralf.westphal]

Zuerst:

Leute die sich kümmern kennen die Prinzipien bereits, sind ja nicht geheim o.ä.
Leute die sich nicht kümmern wird man nicht in einem Kurs vermitteln können warum sie sich plötzlich für ihre Arbeit interessieren sollten.

dann:

man muss auch nicht alles der einschlägigen Literatur gelesen haben wenn man sich kümmert.

Hm... was denn nun? Kann sich nicht einer kümmern und trotzdem in einem CCD Seminar etwas lernen?
Du setzt Kümmern gleich mit "Weiß schon alles über CCD und lernt nichts in einem Training". Das finde ich kurz geschlossen.
Ich lade dich ein, eines unserer Seminare zu besuchen - und wenn du am Ende nichts darüber gelernt hast, wie man Code evolvierbar entwerfen und implementieren kann, dann zahlst du nix. Du als Kümmerer solltest doch eine gute Aussicht auf kostenlose Teilnahme haben, oder? Wie wäre das?

schliesslich meine ich dass "der Teil über Entitäten, Value Objects usw." zum Kern von DDD gehört.

Mit Verlaub: Weil du meinst, das gehöre zum Kern von DDD, heißt noch nicht, dass das auch so ist ;-) Eric Evans sagt in http://www.domaindrivendesign.org/library/evans_2009_1:

Ubiquitous Language and Context Mapping and Core Domain are at the center

Drumherum fliegen dann zwar noch Aggregate - aber höre bei 11:38: "Building blocks are overemphasized".
Und dann höre bei 34:00, dass er gar nicht so sehr darüber nachdenken will, wie ein Konzept wie Aggregate implementiert werden könnte. Eine Haltung, die dich schon im Building Block Kapitel des Buches anspringen muss. Eric Evans ist "Konzeptionalist", aber kein Entwickler. Er hat gute Ideen - aber bleibt dann doch ganz praktische Antworten schuldig. Darin ist auch der Grund zu sehen, denke ich, dass er Jimmy Nilssons Buch empfiehlt, obwohl darin teilweise das Gegenteil von dem steht, was in DDD propagiert wird. Er hat sich einfach nicht mit dem Code auseinandergesetzt. Anders kann ich mir das nicht erklären.

solltest schon ein bisschen an das Glauben worum es geht, oder etwa nicht?

Worum geht es denn? Um OO? Aber OO ist nur ein Mittel. Darum sollte es nicht gehen. Keinen Kunden interessiert, ob du mit OO oder FP oder sonstwas entwickelst. Es geht immer nur um die Erfüllung von Anforderungen heute und in der Zukunft - und das zügig. Also geht es neben den expliziten funktionalen und nicht-funktionalen Anforderungen auch noch um Evolvierbarkeit und Effizienz.

Und nun kommen 20 Jahre OO und zeigen bitte, wie sie Evolvierbarkeit hergestellt und Effizienz erhalten haben.

Jetzt magst du sagen: "Wer halt OO ewig falsch macht, der muss sich nicht wundern."
Darauf sage ich: "Wenn denn OO in 20 Jahren es nicht geschafft hat, die breite Masse in die Lage zu versetzen, ihre Versprechen einzulösen... dann hat OO ein Problem und nicht die breite Masse."

Es geht eben nicht darum, theoretisch irgendwas zu können, sondern das ganz breit dem Dipl. Inf. wie dem Anwendungsentwickler auch relativ einfach in die Hand zu geben. Das aber ist nicht geschehen.

Übungsaufgaben geschrieben von jemandem der nicht an OO glaubt würden was genau beweisen?

Wenn du dir die Mühe machen würdest, die Aufgaben anzuschauen, dann würdest du sehen, dass die mit keinem Programmierparadigma und mit keiner Plattform zu tun haben. Du kannst sie auch mit Pascal oder Clojure oder Lisp oder Haskell angehen. Mir egal. Ich weiß allerdings aus Dutzenden Tests, dass selbst "normale" Java oder C# Entwickler damit so ihre Schwierigkeiten haben. Das liegt natürlich vor allem an soften Faktoren; doch die Programmiersprachen bzw. das dahinter stehende Paradigma macht es auch nicht besser.

Aber versuch es halt mal selbst. Nicht immer nur klitzekleine Code Katas. Die sind ja langweilig. Mach mal was größeres. Und vor allem durch mehrere Iterationen hindurch.

 

[Gregorrr]

In jedem guten SE Buch findet man eine Trennung zwischen System Design und Object Design [Brügge, Dutoit: Object-Oriented SE]. Ralf Westphal hat das unter den Begriffen: konzeptionelle und technische OO untergebracht.

Weil es keine 1:1 Abbildung der Realität auf Entitäten im Code geben kann, das ist doch Utopisch.

Wie will man, denn Parallelität und verteilte Kommunikation im Code darstellen? Task, Prozesse, Threads, Send/Receive, Request/Response. Das sind doch alles Objekte, die Algorithmen kapseln. Und genau das macht die FP Fraktion auch. Und genau das ist der Grund warum auch Java 8 mit: "Ins Zentrum der Aufmerksamkeit hob Reinhold nun Project Lambda, durch das Closures in Java Einzug halten würden, und Project Jigsaw, das sich der Modularität der Sprache annimmt." Einzug findet.

Die Ganzen Servlets, bzw. Java EE ist doch auf Response und Request (substantivierte Verben) aufgebaut.

Ganz zu schweigen von den oben erwähnten Behavioral Patterns. Oder bin ich hier vollkommen auf dem Holzweg? Wie will man denn Modularität, wenn man nicht die Algorithmen abkapseln und austauschbar machen will?

 

[Javalist]

Ich kannte bereits alle Entwurfsmuster und Prinzipien im einzelnen trotzdem hat mir die CCD Schulung sehr viel gebracht. Der Clou ist eben, dass bestimmte Entwurfsmuster im Zusammenhang genannt werden und hier eine gute Zusammenfassung stattfindet.
Maki, ich finde, Du pauschalisierst zuviel und reitest zuviel herum.

 

[Empire Phoenix]

Hallo JanHH,

danke für den Hinweis.

D.h., in den Ebenen, wo ich meist unterwegs bin, Daten schaufeln, DB-Abfragen zur Weiterverarbeitung etc. wird sich für mich OOP garnicht so sehr bemerkbar machen??

Gruss

Sorbas

Würde ich nicht so pauschal sagen, gerade bei der DB kann man das super mit Objecten darstellen.

Zb ich habe die Tabelle person, mache jetzt ein Object für selbige Tabelle, noch eine statische methode ArrayList<Person> search("namenteil"). Wenn ich die jetzt aufrufe lasse ich die gesamt Datenbankarbeit intern innerhalb von dem object erledigen. dann manipuliere ich das object und rufe eine safe() methode auf, die sich weiderum vollkommen autonom um das update,inserten ect Kümmert.

So könnte das dann zb aussehen (pseudo like code)

public static void main(String args){
   ich = new Person("Empire-Phoenix",Gehalt.Lohnsatz5);
   ich.safe();  //hier exepctions werfen, zb wenn es mich schon gibt, oder wenn der Lohnsatz fehlerhaft ist, oder Datenbank Constraints verletzt würden

   meineNamensGefähren = Person.search("Empire");
   for(Person p:meineNamensGefähren){
        p.setGehalt(Gehalt.Lohnsatz9000);
        p.safe();
   }
}

Kurs das Java programm das mit Person arbeitet muss weder wissen ob es sich um ein DB object handelt, noch wie es gespeichert wird. Vorteil: aller Db spezifischer code (querys ect) befindet sich in wenigen Klassen ( dem Model von MVC ), und wenn sich etwas an der DAtenbank änder kann man das schnell anpassen.

Theoretsich könnte Person auch lediglich ein interface sein, und durch den Kontext des Programmes mit einer implementierung dieses Interfaces benutzt werden.

-> SQLPerson
-> TEXTFilePerson (Man könnte ja zb eine textdatei pro person haben)
-> WebServicePerson (Absolut unbekannt wo die person herkommt, man fragt einen Webservice eines anderen Entwicklers lediglich nach den daten, wo die her kommen und wie diese funktioniere kann einen egal sein.

 

[maki]

Zuerst:

dann:

Hm... was denn nun? Kann sich nicht einer kümmern und trotzdem in einem CCD Seminar etwas lernen?

Natürlich, hab ich ja auch nie in Abrede gestellt.
Kannst du mir eine Stelle zeigen an der ich sowas gesagt haben soll?
Oder überhaupt eine Stelle an der ich behaupte dass man bei CCD nix lernen kann?

Du setzt Kümmern gleich mit "Weiß schon alles über CCD und lernt nichts in einem Training". Das finde ich kurz geschlossen.

Das habe ich so auch nie gesagt... irgendwie wird diese Diskussion sinnfrei wenn man nicht auf das eingeht was wirklich gesagt wurde sondern stattdessen auf dinge antwortet die nicht gesagt wurden, anders ausgedrückt: Wenn man seinem gegenüber ständig etwas unterstellt.

Ich lade dich ein, eines unserer Seminare zu besuchen - und wenn du am Ende nichts darüber gelernt hast, wie man Code evolvierbar entwerfen und implementieren kann, dann zahlst du nix. Du als Kümmerer solltest doch eine gute Aussicht auf kostenlose Teilnahme haben, oder? Wie wäre das?

Ist das als Gegenleistung zu verstehen weil ich deine falsche Annahme über das "Erfinden von Entwurfsmustern" korrigiert habe? Die gab es gratis, aber hoffentlich nicht umsonst

Gegenangebot: Du postest hier öfters im Forum und bringst so das Wissen unter die Leute die es so dringend brauchen.

Mit Verlaub: Weil du meinst, das gehöre zum Kern von DDD, heißt noch nicht, dass das auch so ist ;-) Eric Evans sagt in http://www.domaindrivendesign.org/library/evans_2009_1:

Drumherum fliegen dann zwar noch Aggregate - aber höre bei 11:38: "Building blocks are overemphasized".
Und dann höre bei 34:00, dass er gar nicht so sehr darüber nachdenken will, wie ein Konzept wie Aggregate implementiert werden könnte. Eine Haltung, die dich schon im Building Block Kapitel des Buches anspringen muss. Eric Evans ist "Konzeptionalist", aber kein Entwickler. Er hat gute Ideen - aber bleibt dann doch ganz praktische Antworten schuldig. Darin ist auch der Grund zu sehen, denke ich, dass er Jimmy Nilssons Buch empfiehlt, obwohl darin teilweise das Gegenteil von dem steht, was in DDD propagiert wird. Er hat sich einfach nicht mit dem Code auseinandergesetzt. Anders kann ich mir das nicht erklären.

Naja, es ist eine Sache zu behaupten das "der Teil über Entitäten, Value Objects usw. ist der schwächste des Buches" und etwas anderes dass diese Dinge an DDD überbewerted werden, worauf Evans hinaus will ist das der Code an sich nicht Zentrum steht, sondern das Verständnis und die Abstraktion der Problemdomäne.
Verstehe ehrlich gesagt auch nicht was am Code der Aggregate schwierig sein soll (macht man ja auch wenn man sie nicht so nennt), die Aggregate zu erkennen/bestimmen schon eher, aber das hat ja mit Code nix direkt zu tun.
Was er eindeutig schuldig bleibt ist die Antwort wie man die "Application" mit einer GUI verheiratet, aber darum geht es ja auch nciht in diesem Buch.

Worum geht es denn? Um OO? Aber OO ist nur ein Mittel. Darum sollte es nicht gehen. Keinen Kunden interessiert, ob du mit OO oder FP oder sonstwas entwickelst. Es geht immer nur um die Erfüllung von Anforderungen heute und in der Zukunft - und das zügig. Also geht es neben den expliziten funktionalen und nicht-funktionalen Anforderungen auch noch um Evolvierbarkeit und Effizienz.

Und nun kommen 20 Jahre OO und zeigen bitte, wie sie Evolvierbarkeit hergestellt und Effizienz erhalten haben.

Jetzt magst du sagen: "Wer halt OO ewig falsch macht, der muss sich nicht wundern."
Darauf sage ich: "Wenn denn OO in 20 Jahren es nicht geschafft hat, die breite Masse in die Lage zu versetzen, ihre Versprechen einzulösen... dann hat OO ein Problem und nicht die breite Masse."
Es geht eben nicht darum, theoretisch irgendwas zu können, sondern das ganz breit dem Dipl. Inf. wie dem Anwendungsentwickler auch relativ einfach in die Hand zu geben. Das aber ist nicht geschehen.

Denke da übertreibst du jetzt wieder mal.
Richtig, ist nur ein Mittel, aber zu behaupten dass die OO komplett versagt ist einfach zu pauschal.
Die Jahrzehnte davor hatten die prozeduralen Sprachen "versagt", mal sehen wie man in 15 Jahren über FP denkt.

Ist ja nix verkehrtes daran an der Entwicklung teilzuhaben und etwas besseres zu erschaffen bzw. zu nutzen.
Wieder zurückzukehren zu "älteren" Prinzipien die sich auch nicht als Allheilmittel bewiesen haben hilft ja auch keinem auf Dauer.

Wenn du dir die Mühe machen würdest, die Aufgaben anzuschauen, dann würdest du sehen, dass die mit keinem Programmierparadigma und mit keiner Plattform zu tun haben. Du kannst sie auch mit Pascal oder Clojure oder Lisp oder Haskell angehen. Mir egal. Ich weiß allerdings aus Dutzenden Tests, dass selbst "normale" Java oder C# Entwickler damit so ihre Schwierigkeiten haben. Das liegt natürlich vor allem an soften Faktoren; doch die Programmiersprachen bzw. das dahinter stehende Paradigma macht es auch nicht besser.

Aber versuch es halt mal selbst. Nicht immer nur klitzekleine Code Katas. Die sind ja langweilig. Mach mal was größeres. Und vor allem durch mehrere Iterationen hindurch.

Das man Probleme mit verschiedenen Sprachen lösen kann ist nichts neues.
Mir ging es um deine Behauptung:

Die konzeptionelle OO hat - wie man landauf-landab sehen kann - offensichtlich nicht fehlerfreiem und evolvierbarem Code geführt. Seit 20 Jahren verspricht sie das aber den "Entwicklermassen". Auch Entwurfsmuster und UML haben es nicht hinbekommen. Projekte stehen bis zur Hüfte in Unwartbarkeit. Selbst ohne eine Vorstellung davon, wie es anders gehen könnte, sollte daher klar sein, dass es so nicht weitergehen kann. Auch Clean Code ist da nur eine Symptomkur. Das merkt jeder, der bei einem Refaktorisierungsmarathon nach Namen sucht für die immer kleiner werdenden Klassen; denn zu nichts anderem führen Prinzipien wie SRP, SoC, SLA oder KISS. Soviele Managers, Controllers, Coordinators kann es gar nicht in einem Softwaresystem geben... Aber wie dann solche Klassen bezeichnen?

Refactore lange & regelmässig selber genug um zu wissen dass es eben nicht immer zwangsläufig mit Managern/Conttrolern/Coordinatoren endet.
Wohin einen das Refactoring treibt steuert man zum Grösstenteil selber, vielleicht nicht immer bewusst, aber keines der Micro-/Macrorefactoring legt von vornehrein als Ziel einen Controller/Manager fest.

Mich würde es sehr freuen wenn diese Diksussion nicht mit so vielen Unterstellungen und Emotionen geführt werden könnte