Ja, weiter geht es mit dem nächsten Abschnitt.
Sie sehen ja, im Nudel,
wir haben ihre Hinweise befolgt, es gab den Wunsch,
dass wir dort durch die Links wieder sichtbar machen.
Andererseits gab es den Wunsch dafür in der besseren Download-HTMM5-Code zu machen.
Wir haben jetzt beides. Dann gibt es den Link im Nudel
und den HTMM5-Code. Also wir freuen uns über all Ihre Hinweise.
Das war jetzt eine Sache aus dem Feedback zu unserer Vorlesung,
die wir vor zwei Wochen abgefragt haben.
Jetzt haben Sie hier doch eine ganze Menge Leute beteiligt.
Vielen Dank an alle Beteiligten und das, ich hoffe,
Sie profitieren alle davon. Wir machen hier weiter mit Entwurfsqualität,
Regeln für guten Entwurf in Kredienzen, Was sollte man da alles haben?
Und jetzt die Frage, was sind denn gute Schnittstellen für diese Komponenten?
Wir haben schon gute Komponenten gewählt, nach Kopplung,
nach enger Kommission, nach loser Kopplung, nach Zuständigkeiten.
Und jetzt, wie sollten die Schnittstellen aussehen? Schnittstellen so,
dass diese Abhängigkeiten möglichst wenig sind. Und natürlich soll die Schnittstelle korrekt sein,
im Sinne gut sein, im Sinne von vollständig,
im Sinne, ach ja, haben wir vielleicht noch einen,
wie kriege ich das hin, dass hier ist der Leserpunkt, ja, genau.
Im Sinne von vollständig im Sinne von klar, konsistent,
dass man immer das Gleiche hat,
dass man das erwartet
Dass sich die Menschen zurechtfinden. Die Software,
dass sie funktioniert, das ist kein wichtiges Kriterium.
Funktionierend. Also das ist eines der dümmsten Argumente, funktioniert sogar.
Wichtig ist, dass es andere gut verstehen. Das ist
guter Entwurf. So und natürlich kann es manchmal passieren,
dass es Sachen gibt, wo wir sagen müssen,
das wäre jetzt besser für Testbarkeit, dass wir besser für Verständlichkeit,
dass wir besser für Performance, dann müssen wir manchmal abwägen.
Ja, also welches Ziel ist uns das Wichtige?
Wir schauen mal an, was wir davon haben.
Natürlich haben Sie schon kennengelernt,
Java hat Interfaces
Interfaces sind erstmal die Schnittstellen nach außen, ja. Und dieses Sprachkonstrukt können wir verwenden,
um die Implementierung, das heißt,
das Innere zu trennen von dem, was nach außen sichtbar ist,
auch mit dem Ziel Änderungen zu erleichtern, nämlich,
dass wir leichter mal innen was ändern können,
zum Beispiel, da gibt es einen Fehler,
da gibt es eine bessere, wir brauchen mehr Performance,
wir brauchen bessere Speicherverwaltung oder was auch immer,
wir möchten es intern ändern und die anderen sollen möglichst davon gar nichts mitkriegen,
deswegen haben die anderen möglichst Schnittstelle und sie benutzen
die Implementierung nicht
Dieses Entkoppeln voneinander. Lose Kopplungen. Das ist immer das
gleiche Märchen, das hier von uns hören. Ja,
und wir benutzen, wir geben nur das hinaus,
was andere benutzen sollen, nur das geben wir vor.
Wir machen die Schnittstellen so, dass der Klient sie gut benutzen kann.
Ja, und wir machen die Kopplung lose und deutlich.
Ja, und wir wollen versuchen natürlich Zyklen aufzulösen.
Ja, so. Und dann versuchen wir,
das in diese Lose, wie heißt es, Entkopplung.
Lose Kopplung zu erreichen, indem wir das Interface gut gestaltet
So, und das können wir zum Beispiel so machen,
dass wir hier ein Interface haben, Vormerk-Service,
was dann da genutzt werden kann vom Vorwerk, vormerk-Werkzeug.
Ja, und dahinter steht dann etwas anderes. So,
ich zeige mal ein Beispiel, wie sowas aussehen kann.
Nehmen wir mal an, wir haben eine geschachtelte Gui,
das war ja vom letzten Mal,
hierarchischer Aufbau von grafischen Benutzerschnittstellen, das machen wir jetzt.
Und jetzt schauen wir mal, wie wir das gut tun,
um gut Schnittstellen zu gestalten.
Ja, also wir haben uns so ein Hauptfenster,
das ist ein J.Frame, wir haben Border Layout,
wir haben oben Komponenten unter das Label
Und dann gibt es so die mittlere Komponente Draft Panel.
Ja, das kann etwas darstellen. So, und jetzt
haben wir ein Problem, die müssen sich kennen. Ja,
also das Hauptfenster hier in der Mitte, das Hauptfenster,
das Große, muss das Craft Panel kennen,
damit man beim Klick wirklich das erzeugen kann.
Ja, aber das muss auch das kennen. Wechselweise kennen ist irgendwie,
sie erinnern sich schon, hoffentlich, ja, Zyklen war das Stichwort.
Typen sind böse, weil sie halt das schwer erlauben,
was man testet, weil sie es stark verhindern,
dass man mittiert, dass man Änderungen übernimmt.
Ja, und wir können das so machen, dass wir
nicht dass wir nicht alles kennen, sondern nur eine Schnittstelle.
Ja, nehme ich nur eine Schnittstelle mit Meldungen.
Diese Meldungen könnte man zum Beispiel über so Beobachtermuster implementieren.
Das könne man gut machen und damit das auflösen.
Das ist letztlich nichts Neues, was wir können.
Natürlich müssen die sich irgendwie am Ende doch informieren. Ja,
aber es ist nicht so, dass die eine,
das eine, das andere gegenseitig referenziert,
sondern es weicht da eine Nachricht hin zu salieren und das zu implementieren.
Ein wichtiger Punkt. Der nächste wichtige Punkt ist,
auch wieder mit dem gleichen,
wir haben immer
das gleiche Ziel entkoppeln
Koppeln, hier für Entscheidungen, dass ich eine Entscheidung nicht
so stark woanders hin auswirke. Wenn wir das eine ändern,
zum Beispiel, weil sich die Ziele verändert haben,
bisher war für uns ganz wichtig, Performance, Performance,
Performance, ja, zum Beispiel ein Shop-System für den Weihnachtsverkehr aufbereiten.
Und jetzt wollen wir, dass das System in der Sicherheitsanforderung, Korrektheitsanforderungen erfüllt.
Ja, und da müssen wir intern was ändern.
Es soll sich nicht nach Größen ausbreiten, deswegen wollen wir,
dass die lokale Entscheidung zum Beispiel das Fremdwoch beverwenden oder welches muss man,
wenn nur da drin bleibt.
Ja, so
Beim Entwurf treffen wir Entwurfsentscheidungen. Ja, das hängt natürlich
von einer anderen Entscheidung hängen davon ab. Das heißt,
wir versuchen, die Basisentscheidungen, die wir möglichst nie mehr ändern,
wie so ein Framework oder sowas, dass wir die zuerst treffen.
Ja, und wie die sich sehr wahrscheinlich ändern,
wie zum Beispiel, wie sieht das Logikfehl aus,
das noch mehr etwas später.
So, dazu ist es wichtig oder ein weiterer Punkt,
auch wieder um diese Entkopplung zu erreichen.
Sie hören immer das Gleiche. Entkopplung im Sinne von Teams
können gut arbeiten. Wir können innerhalb der Arbeit organisieren.
Ist das Geheimnisprinzip
Dieses Geheimnisprinzip, wenn Sie jetzt sagen, was erzählt der
Dezentrum Sascha wieder? Haben wir doch schon längst gehört.
Ja, haben Sie schon gehört mit dem Unterfix.
Das Interface hat auch schon Trennung von Schnittstellen und Implementationen.
Das Geheimnisprinzip sagt das Gleiche, nur ein bisschen mit anderen Worten.
Wir sollen nur das, was relevant ist,
sollen wir nach außen sichtbar machen. Nur das, was
man auch benutzen soll, die Details sollen verborgen bleiben.
Damit man das Wissen nicht verpackt. Ja, und jetzt
hier sehen Sie mal, wann das jemand erfunden hat.
Japaners ist einer der alten Herren der Informatik.
Ich habe soweit das Glück gehabt, mich immer kennenzulernen,
war auf jeden Fall halt ein bisschen unleitlich im Bezirk
Ein bisschen rechthaberischer. Naja, er hat viele Clash-Sachen,
Sachen wollen sich gegeben und er hat 1972 schon das Geheimnisprinzip als
ganz wichtiges Prinzip für Gruppenentwurf entdeckt, formuliert, sag mal lieber.
Das Prinzip gab es schon vorher,
das hat damit zu tun, wie Menschen miteinander arbeiten.
Und das Bild des Eisbergs später ganz gut.
Sie wissen nur ein Zehntel des Eisbergs, guckt oben raus.
Deswegen hat es bei der Titanic damals diesen großen Crash gegeben.
Also wenn sie da einfach über so ein Eis mehr fahren,
werden sie vorsichtig, wenn da nur wenig oben rausguckt.
Und wir versuchen auch nur wenig für die anderen rauszugucken zu lassen,
nur das benutzen, um wir hier unten beliebig Sachen ändern können,
ohne dass es auf die anderen eine Auswirkung hat.
Das ist eines der wichtigen Prinzipien. So, Zyklen haben Sie schon
ein paar Mal gehört. Warum sollen wir Zyklen nicht machen?
Zyklen sind schwierig fürs Test. Und das eine,
das andere, wir können die nicht unabhängig voneinander testen.
Wenn wir in der Zelle Objekte initialisieren sollen, ist immer nicht klar,
wer wird zuerst initialisiert und informiert dann die anderen,
wenn es einen Zyklus gibt, wir können so eine Entwicklschleife von Aktualisierung machen,
eine Initialisierung machen.
Und der Einstiegspunkt ist unklar
Sie können es zwar hinkriegen jetzt und gleich,
aber ob Ihr Kollege das in drei Monaten versteht,
wo der Einstiegspunkt ist, am besten ist keine Zyklen.
So, und deswegen wollen wir versuchen, zyklische Abhängigkeiten zu vermeiden. Beispiel,
wie können wir solche Paketzyklen vermeiden,
das haben die schon kennengelernt, mit den Regeln für SE2-Komponenten,
für die wannen Komponenten, ja, die waren Bestandteile,
das Werkzeug kennt eben Servicematerial im Fachwert,
aber der Fachwert muss nichts kennen.
Der Fachwert ist unabhängig voneinander. Das Material ist abhängig
nur vom Fachwert
Und dafür, es kennt nicht das Werkzeugkind, nicht den Service.
Ja, ich muss also, das Material muss nicht geändert werden,
wenn sich Werkzeug oder sorgen sind. Das ist etwas,
was wir dann erreichen und die Pakete sind dann, denen gleicherweise ihre Abschlusszeiten.
Das hilft uns, die Arbeit besser zu organisieren,
das so zu strukturieren und besser rauszubekommen,
wo muss ich denn schauen für potenzielle Abschlusszeiten?
Und sie erinnern sich, vor ein paar Minuten habe ich
darüber gesprochen, das ist auch inplizite Abhängigkeiten gibt,
auf die müssen wir auch achten.
Nicht nur die FD, die ich im Quelltext
ins Prinzip sehe
Und wir finden dann, wenn wir das einmal
so formuliert haben, können wir dann da plötzlich prüfen.
Da gibt es auch Werkzeuge, die das prüfen, wie das aussieht.
Sowas lernen sie zum Beispiel Master bei, zum Beispiel bei mir,
eben Softwarearchitekturen und Softwarere-Engineering wird es oder Änderungen von Systemen gibt.
Sind Sie herzlich eingeladen? Aber wir sind noch da
noch nicht und wir haben noch einen weiteren Punkt,
auch wieder für guten Entwurf.
Und zwar die Kate. Ja, Duplikate sind etwas,
was ganz häufig vorkommt. Man macht die ganz bequem durch Copy-Paste.
Ja, Copy-Paste ist ja, da gibt es was Ähnliches,
das kann ich irgendwie brauchen in einer ähnlichen Form
Könnte ich doch mal hier, ich mache ein Fenster aus und noch ein Fenster,
ich schreibe das nicht komplett ab, sondern ich kopiere das einfach.
Super, ja, ich werde schneller fertig,
hat aber ein paar kleine Nachteile. Und eins,
also nur, dass sie wissen, so mein Herr,
habe ich ja mir meine Schätzung mit auf die Folie genommen,
man kann davon ausgehen,
dass bei jedem Programm durchschnittlich zwischen 5 und 25 Prozent des Tods irgendwie mehrfach vorkommen.
Und das ist schon eine beträchtliche Menge,
wenn wir also 100.000 Lines of Code haben,
dann sind vielleicht 25.000 Lines of Code gar nicht nur einmal da,
sondern sind irgendwie mehrfach. Ja, so,
eigentlich würden wir sagen, copy paste super bin ich nerv,
hatte ich mit meiner Arbeit, aber Meistens weiß ich nicht,
wo kommt das denn noch alles vor.
Und ich muss, wenn ich ein Problem habe,
zum Beispiel hier eine Sicherheitslücke oder was anderes oder ich will einfach nur eine Änderung machen.
Ich muss alle Stellen kennen. Und das ist meistens nicht da.
Und sie können sich vorstellen, wie bösartig solche Fehler sind.
Ich hatte das mal in einem Projekt, da war ein
ganzer Dialog doppelt, das hat man die Leute nicht gewusst.
Der Entwickler hat einen Ausmaß gekriegt, da sagen wir mal was ganz Simples,
nur eine Bezeichnung sollte in der Tabelle verändert werden.
In so einem Dialog, was ich bekomme, du bockst,
da soll eine Bezeichnung ändert werden. Der hat das auch gemacht,
eingecheckt, hat im Auftraggeber gesagt, ja,
ist drin in der nächsten Version und der sagt,
willst du mich verarschen,
es ist nicht drin.
Und deshalb habe ich
doch gemacht
Und dann sind wir drauf gekommen, es gab den Dialog zweimal.
Dumme Falle, wie stehen wir denn da? Kriegen wir
so etwas Einfaches wie als Entwicklerteam kriegen wir so was anderes
wie mit dem Text, ändern mich hin, scheinbar.
So, das liegt daran, also da gibt es natürlich
viel bösere Fehler. Und natürlich,
was ich auch nicht sagen möchte, es ist einfach,
wenn der 25-Prozent-Duplikate haben, ist 25 Prozent mehr Kot da.
Ja, ich muss mir ja verstehen,
ich muss mir analysieren, ich muss mehr pflegen.
Ich will mal gleich noch hinzufügen,
es steht nicht auf dieser Folie,
null ist kein erstrebenswertes Ziel,
weil manchmal sind Duplikate
auch zitabel
Nämlich insgesamt, dann, wenn ich sonst Zyklen hätte,
wirklich, sie wissen gleich die Lösung, die wir hier haben,
steht nicht mit auf der Folie, aber wir können gleich sagen,
okay, ich kann ja das auslagern,
eine gemeinsame Oberklasse, ja,
oder durch Delegation oder Interface oder sowas.
Das wäre die Lösung. Manchmal kann ich das nicht machen,
weil ich dadurch Zyklen hätte. Ja, dann ist das
tatsächlich akzeptiert. Aber 25 Prozent müssen nicht sein. So,
wir nehmen diese Kotoplikate hier im Zusammenhang mit gutem Entwurf als ein Zeichen,
das etwas Schlechtes mit unserer Kurvision, ja, also Sachen,
wo die zusammengehören, Das soll nicht ein Teil woanders noch sein.
Ja, dieses Teil, was woanders ist,
ist dann, gehört ja eigentlich hierher.
Und da ist die Kursion dann nicht da. So,
das Ganze zusammengefasst, was ich jetzt länglich dargestellt habe,
sind diese ganz wunderbaren Sönneprinzipien.
Die sollen in Prinzipien hören wir gleich nochmal im Java.
Ja, und wir haben die alle nochmal hier zusammen.
Also die Zuständigkeiten. Single Responsibility, wo es erbrechen auf
Konzerns dazu halt, dieses CRC-Karten, die waren dafür.
Open Closed, Änderungen sollen sich
nicht auswirken
Ja, Änderungen sollen lokal bleiben. Das hat was mit
Kapselungen, Information Heading zu tun. Dann haben wir etwas,
was wir in der vergangenen Vorlesung schon mal hatten, dieses Ersetzen von Unterklassen.
Das hatten wir, als wir die VR verschickt,
bei den Typen von Vererbung. Sie erinnern sich hoffentlich,
Typ Vererbung in die Mentationsfärbung, als wir die gesprochen haben,
hatten wir auch mit dieser Verschärfung von Bedingungen für Design bei Contract gesprochen.
Wenn Sie jetzt nicht mehr genau wissen,
wovon ich spreche, schauen Sie es nochmal an.
Sie haben es ja einfach, Sie sind alles als Video da.
So, und dann, dass wir die Interfaces so gestalten,
dass der Anwender gut was damit machen kann
Diesen Abschnitt Interfaces hatten wir heute auch. Und dass wir die Abstraktionen,
dass das nur für eine Attraktion abhängt,
von der Nürnberg ist auch über etwas mit Typen und Verwaltung,
habe ich jetzt nicht so,
bin ich nicht so ganz genau darauf eingegangen,
zu den Vermeidungen reicht uns hier.
Auf jeden Fall niedrigere Kopplungen, hohe Kollision,
das hören Sie hier von mir immer wieder.
Dazu haben wir eine der Fragen, mit der springen wir
mal schnell, erklären Sie die Solle im Prinzip.
Also Sie sollten in der Lage sein,
das hier zu erklären