Probleme beim Einloggen
Christian Rehn Fragen zu IOSP
Hallo!
CCD definiert 20 Design-Prinzipien und zu diesen hätte ich ein paar Fragen in der Hoffnung, dass ich hier Leute finde, die diese nutzen und sich damit auskennen.
Kurz zum Hintergrund:
Ich beschäftige mich seit geraumer Zeit mit solchen Prinzipien hab darüber schon vor Jahren meine Masterarbeit geschrieben und ein Wiki dazu erstellt. Basierend auf unseren "Design Types" bin ich zusammen mit einem Kollegen jetzt dabei, Prinzipien auf Karten zu bringen. Da wir erstmal "nur" 54 Karten zur Verfügung haben, es aber weitaus mehr Prinzipien gibt, müssen wir eine Auswahl treffen. Eine möglichst hilfreiche natürlich, d.h. zum einen sollten die Prinzipien möglichst viel abdecken und breit anwendbar sein, zum anderen sind spezifische Prinzipien manchmal nützlicher als allgemeine, weil sie leichter zu verwenden sind.
26 von 54 Karten sind quasi schon fertig (und bei diversen Pilotgruppen in der Erprobung), der Rest ist grob skizziert. Bisher ist IOSP nicht als Karte angedacht, wohl aber SLA. Nach meinem aktuellen Verständnis bedingt SLA IOSP. Wenn ich mich an SLA halte, halte ich mich automatisch auch an IOSP. Demnach wäre IOSP eine Spezialisierung, ein Sub-Prinzip. Für unsere Karten könnten wir im konkreten Fall deshalb auf IOSP eher verzichten als auf SLA.
Deshalb meine Fragen zu IOSP:
1. Hab ich IOSP richtig verstanden oder gibt es Fälle, wo IOSP hilft und SLA nicht ausreicht?
2. Wenn IOSP ein Sub-Prinzip ist, ist es aber vielleicht leichter anwendbar. Wie sieht es hier mit praktischen Erfahrungen aus? Wer nutzt IOSP und warum?
Johan Samyn Christian Rehn Stefan Lieser Ralf Westphal
+5 weitere Kommentare
Letzter Kommentar:
Christian Rehn
Danke. Das kann ich nachvollziehen.
Also thanks a lot for mentioning the blog post about control structures. It's a very nice treatise on tradeoffs.
Stefanie Rentzsch Daimler - RecruitingDay ‘ Autonomes Fahren hautnah erleben’ am 23. Juli
Liebe Gruppenmitglieder,
Daimler sucht Talente die an dem Zukunftsfeld ‘Autonomes Fahren’ mitarbeiten möchten. Jetzt können Sie sich noch bewerben für den RecruitingDay - ‘get in touch’ am 23. Juli 2018 in Sindelfingen!
Möchten auch Sie die Zukunft des Automobils mitgestalten? Möchten Sie das selbstfahrende Auto auf die Straße und in Serie bringen? Dann bewerben Sie sich noch bis zum 01. Juli 2018 unter https://www.daimler.com/karriere/das-sind-wir/events-workshops/eventuebersicht/event-detailseiten/2018/recruitingday-get-in-touch.html und entdecken Sie Ihre Einstiegsmöglichkeiten im Bereich „Autonomes Fahren“ bei Mercedes-Benz Cars der Daimler AG.
Die Kosten für die An- und Abreise werden von der Daimler AG übernommen.
Die Daimler AG freut sich auf Ihre Bewerbung.
Viele Grüße
Steffi
Stefanie Rentzsch Daimler - RecruitingDay ‘get in touch' in Sindelfingen
Liebe Gruppenmitglieder,
Daimler sucht Talente die an dem Zukunftsfeld ‘Autonomes Fahren’ mitarbeiten möchten. Jetzt können Sie sich noch bewerben für den RecruitingDay - ‘get in touch’ am 23. Juli 2018 in Sindelfingen!
Möchten auch Sie die Zukunft des Automobils mitgestalten? Möchten Sie das selbstfahrende Auto auf die Straße und in Serie bringen? Dann bewerben Sie sich noch bis zum 01. Juli 2018 unter https://www.daimler.com/karriere/das-sind-wir/events-workshops/eventuebersicht/event-detailseiten/2018/recruitingday-get-in-touch.html und entdecken Sie Ihre Einstiegsmöglichkeiten im Bereich „Autonomes Fahren“ bei Mercedes-Benz Cars der Daimler AG.
Die Kosten für die An- und Abreise werden von der Daimler AG übernommen.
Die Daimler AG freut sich auf Ihre Bewerbung.
Viele Grüße
Steffi
Ralf Westphal Jenseits von OOP und FP
Robert C. Martin hat etwas zur Co-Existenz von OOP und FP geschrieben. Das fand ich gut - war aber am Ende doch enttäuscht. Es fehlte (wieder mal) das Wesentliche an der Objektorientierung.
Und am Ende blieb es natürlich bei den Etiketten OOP und FP, statt die Diskussion auf die prinzipielle Ebene zu heben. Auch wenn Aggregationen wie OOP und FP manchmal das Gespräch leichter machen, weil sie für Mengen an Werten und Prinzipien stehen, ist es für die Praxis untauglich, auf dieser abstrakten Ebene Lösungen zu suchen.
Mir war aber vor allem wichtig, das zentrale Problem zu benennen, das weder OOP noch FP angehen: funktionale Abhängigkeiten. Die machen Code schwer verständlich und schwer testbar. Da hilft auch SOLIDe Programmierung nur wenig.
Wer das ausführliche dargestellt sehen will, der lese hier:
Enjoy - and discuss! :-)
-Ralf
http://ralfw.de
http://ccd-school.de - Jetzt auch mit Personal Training
Denis Kuniss
+4 weitere Kommentare
Letzter Kommentar:
Ralf Westphal Abstraktion in der Softwareentwicklung - aber wie?
Über Abstraktionen wird in der Softwareentwicklung ja immer wieder geredet. Da soll von Details abstrahiert werden (Kapselung), es gibt abstrakte Klassen und man soll sich nicht von Konkretem, sondern von Abstraktem abhängig machen (DIP).
Klingt alles irgendwie sinnig - scheint mir jedoch am Ende doch nicht klar zu sein. Ich finde die Verwendung des Begriffs "Abstraktion" oft sehr pauschal und lückenhaft.
Mit zwei Artikeln versuche ich deshalb, das Dickicht zu lichten. Abstraktion ist nämlich nicht gleich Abstraktion.
* https://ralfw.de/2018/03/bequeme-abstraktion-ganz-konkret/ - eine Begriffsdifferenzierung
* https://ralfw.de/2018/04/all-together-now-schrittweise-abstrahieren/ - die schrittweise Nutzung von differenzierter Abstraktionen am Beispiel
Enjoy and discuss! :-)
-Ralf
http://ccd-school.de - Clean Code Development Training inhouse und online
Denis Kuniss Alexander Kriegisch Maximilian Raab
+27 weitere Kommentare
Letzter Kommentar:
Denis Kuniss

>Hier der komplette Text zur schrittweisen Verfeinerung: https://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf
>Das ist eine Problemlösungsmethode - aber für mich ist es wichtig, dass das Ergebnis sich im Code widerspiegelt. Deshalb das IOSP.
Ich sehe Eurer IOSP Prinzip als als Essenz und als Weiterentwicklung dieser Methode. Mein Kommentar war auch eher als Hinweis gedacht, wie man konservative Kollegen für diesen neuen Ansatz interessieren kann. Manchmal ist es wichtig, eine solchen Anker zu bieten, um den Wiedererkennungseffekt auszunutzen und Unsicherheiten auszuräumen. Der kognitive Sprung von der wohl bekannten Wirth'schen Methode (und viele ältere Kollegen hatten Wirth und seine Methode im Studium, aber OOP haben sie sich im Selbststudium beigebracht) zum IOSP ist dann kürzer und einfacher, weil man sich auf etwas stützen kann, was man schon kennt. Das schafft Vertrauen. Das neue an IOSP zu entdecken und zu verstehen ist dann einfacher, denke ich.
Also eher ein didaktischer Hinweis, etwas, das ich in meine Artikeln dazu auch schon verwendet habe.
Danke für den Link.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.982
  • Sichtbarkeit: offen
  • Beiträge: 479
  • Kommentare: 2.979