Probleme beim Einloggen

Dieser Beitrag wurde wegen "Crossposting" gelöscht.

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.
Samuel Nitsche Practical Advice for Taking Your PL/SQL Testing to the Next Level - Dienstag 24.4. 18 Uhr
Automatisiertes Testing ist eine Grundvoraussetzung für sinnvolles Refactoring und praktische Umsetzung von CleanCode. Insbesondere in Bezug auf Datenbank-Entwicklung gibt es hier nach wie vor sehr viel Luft nach oben.
Mitglieder der utPLSQL Community geben nächsten Dienstag in diesem kostenlosen Online-Webinar praktische Einblicke und Tipps zur Einführung von automatisierten Tests in Datenbank-Projekte - insbesondere auch mit Fokus auf bestehende "legacy"-Projekte. Mit einfachen, realitätsnahen Beispielen wird auch gezeigt, wie sich Datenbank-Tests in eine Continuous-Integration (CI)-Pipeline integrieren lassen.
Ralf Westphal Die Agilität eine Saunabank nach oben setzen
Die Agilität ist nun schon recht betagt und nicht alles ist rosig im agilen Land. Deshalb habe ich mir mal das Agile Manifest genauer angesehen. (Auch aus dem Impuls heraus, den mir XDSD gegeben hat (s. separater Thread hier).)
Die bottom line: Ich glaube, dass die Lunte des wahren Sprengstoffs, der in der Agilität steckt, noch nicht angezündet wurde. Das Agile Manifest ist durch alte Brillen interpretiert worden - was ja auch verständlich ist. Dadurch wurde jedoch noch nicht voll realisiert, was möglich und notwendig ist.
Bisher sitzen die Implementierer der Agilität also eher in der Sauna noch unten ;-) Damit es weiter vorangeht, steht nun an, mal eine höhere Bank in der Saune zu besetzen. Auch wenn das erstmal nicht so angenehm sein mag.
Eduard Ruffert Denis Kuniss Alexander Kriegisch
+5 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
Ich unterscheide zwischen einer "Agilität, wie sie gemeint war" (oder gemeint gewesen sein könnte; ich war ja nicht bei der Unterzeichnung dabei) und einer "real existierenden Agilität".
Letztere verdient eine höhere Saunabank :-)
Im Agilen Manifest steckt viel mehr, als getan wird. Und - ja, dabei bleibe ich - das Agile Manifest ist eben auch nur ein Kind seiner Zeit. Auch darin ist nicht alles gesagt und gelöst.
Dass irgend "nix neu" in dem ist, was ich geschrieben habe... Nun, das mag sein. Ist ja aber eine Aussage über Texte jeder Art, die seit 1000 Jahren so gilt. Nicht immer geht es darum, etwas Neues zu sagen. Manchmal (oder meistens?) ist es schlicht hilfreich, Altes nochmal irgendwie anders zu sagen. Das ist dann ein Akt der Reflexion und macht das Alte (hoffentlich) einem noch weiteren Interessentenkreis zugänglich.
Anschlussfähigkeit ist nicht sofort gegeben, nur weil einer überhaupt etwas sagt. Sogar eher weniger, wenn jmd etwas Neues sagt. Insofern braucht es Übersetzungen und Anpassungen und Umformulierungen.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.954
  • Sichtbarkeit: offen
  • Beiträge: 477
  • Kommentare: 2.973