GoF-Pattern im Programmierer-Alltag

[Wuast]

Hallo Leute,

ich brüte im Rahmen eines Kurses zum Software-Engineering über einem Buch, welches in einem Kapitel einige der GoF-Pattern vorstellt, z.B.
neben Observer auch Adapter, Fassade, Strategy, Abstrakt Factory, und viele weitere...

ich bin etwas erschrocken, wie sehr man das Programmieren in "richtigere" oder / gute "Lösungswege" einsortieren kann (was ja andere Lösungswege irgendwie erstmal entwertet).
Jedenfalls scheint mir zunächst vom ersten Lesen her das Erlernen der ganzen Pattern extrem schwierig, z.B. die alle erstmal überhaupt zu behalten und dann auch noch für mich umsetzbar zu machen. Bisher bin ich auch auf diese abstrakte, theoretische Art noch nicht an Pattern herangeführt worden, sondern nur sehr vereinzelt und dann ggf. über konkrete Aufgaben oder Hinweise von euch hier aus dem Forum. (also eigentlich kannte ich bisher "nur" Singleton, Observer, Factory)

Gehören diese ganzen anderen GoF-Pattern zum Standard-Werkzeug im Arbeitsalltag, also sitzt man dann da und denkt sich "ahh, hier nutze ich jetzt das Pattern xyz weil ... " und "macht das dann einfach"? Macht man das mit der Zeit oder muss ich das knüppelhart wie andere Grundlagen auch lernen, wie man ja auch z.B. lernen muss, was Variablen und Klassen sind etc. ?

Bin etwas erschrocken, was da alles noch lauert und wie sich ein etwaiger Erwartungshorizont an Entwickler noch verschieben kann...
Also meine Frage an Leute aus der Praxis: Wo, wie (oft) und wie bewusst begegnen euch diese ganzen GoF-Pattern im Berufsalltag?

Ich wünsche euch ein schönes Wochenende!

 

[M.L.]

"richtigere" oder / gute "Lösungswege"

Im Endeffekt ist der Compiler (Interpreter, Transpiler,...) die entscheidende Instanz was formell korrekten Code angeht WIE dieser zustande kommt ist dieser Software eher egal. Die (Nicht)Anwendung von Mustern (i.S.v. Lösungswegen) spricht nicht für oder gegen die Professionalität der jeweiligen SW-Lösung.

Muster dienen dem Menschen ("Teile und herrsche-Prinzip"), stellen bekannte Wege (also mit Vor- und Nachteilen) zu einer Problemlösung dar und dienen dem (häufig(er)en) Ändern oder Erweitern einer Software. Wobei man die Muster in freier Wildbahn -je nach Priorität- mit unterschiedlicher Wahrscheinlichkeit antreffen und nutzen wird.

[Zusatz] Muster können auch aufeinander zugreifen: https://javarevisited.blogspot.com/...ava-programmers-developers.html#axzz7m0BdfcUX

 

[White_Fox]

Wenn ich mir als ausgewiesener Nichtprogrammierer mal eine Antwort erlauben darf, vom Programmieren habe ich keine Ahnung:

Also meine Frage an Leute aus der Praxis: Wo, wie (oft) und wie bewusst begegnen euch diese ganzen GoF-Pattern im Berufsalltag?

Manche Entwurfsmuster begegnen dir ständig und immer wieder. Wenn du sie nicht selber schreibst, dann begegnen sie dir auf jeden Fall in Bibliotheken.

ich brüte im Rahmen eines Kurses zum Software-Engineering über einem Buch, welches in einem Kapitel einige der GoF-Pattern vorstellt

Ist es zufällig "Entwurfsmuster von Kopf bis Fuß"? Wenn nicht, solltest du dieses Buch gegen jenes eintauschen. Danach ergeben Entwurfsmuster für dich auf jeden Fall sehr viel Sinn und ich behaupte mal, daß du danach der Meinung sein wirst, OOP vorher noch nicht richtig verstanden zu haben.

 

[thecain]

Mein Code wird aber auch von Arbeitskollegen gelesen und die sind in der Regel keine Compiler. Zudem will ich wartbaren und erweiterbaren Code.

Pattern helfen dies zu erreichen und es macht mMn auf jeden Fall Sinn sie zu kennen und auch, wo sinnvoll, einzusetzten. Wann das es sinnvoll ist, wirst du mit der Erfahrung lernen.

 

[LimDul]

Kommt jetzt auf die Sichtweise an. Im Prinzip komme ich - wenn ich mal entwickeln darf - täglich an Patterns vorbei. Bewusst wahrnehmen aber eher selten. Es ist auch gefährlich sich zu sehr auf Patterns zu versteifen. Es sind Lösungen/Werkzeuge für bestimmte Probleme und passen nicht immer. Die Methode "Welches Pattern könnte ich den jetzt noch anwenden" ist oft nicht zielführend.

Wichtig sind Patterns als Kommunikationsmedium. Wenn ich mit jemanden über einen Visitor spreche ist dadurch eindeutig definiert, was gemeint ist und man redet (hoffentlich) nicht aneinander vorbei. Und das geht einem sukzessive in Fleisch und Blut über. Ich könnte dir aber auch nicht alle im Detail erklären.

 

[mihe7]

Die Patterns begegnen einem ständig, auch wenn das oft nebenher läuft und das hat einen Grund: ein Design Pattern ist einfach ein Weg, um ein bestimmtes Problem zu lösen und weil es oft nicht der schlechteste ist, finden die Patterns natürlich auch in den Frameworks Anwendung, mit denen man täglich zu tun hat.

Wenn Du z. B. eine Swing-GUI schreibst, kommst Du an Listener nicht vorbei und schon hast Du das Observer-Pattern verwendet. In JavaFX ist das ein ganz zentraler Bestandteil. Baust Du eine Undo-Funktionalität via UndoManager ein, hast Du auch schon das Command-Pattern verwendet. Willst Du mal alle Dateien in allen Unterverzeichnissen auflisten, stehen die Chancen gut, dass Du Files.walkFileTree() verwendest. Dann implementierst Du einen FileVisitor, setzt also das Visitor Pattern ein. Darüber verliert man aber keinen Gedanken.

Was das eigene Design betrifft, kommt man natürlich auch immer wieder mal auf das ein oder andere Pattern zurück: Builder, Factory und Strategy würde ich mal als erste nennen. Aber, da spielen dann andere als die GoF-Patterns m. E. eine bedeutendere Rolle, auch wenn sich diese ggf. auf die GoF-Patterns zurückführen lassen. Das sind dann Patterns wie MVC, Domain Model, Repository oder auch mal das Actor-Role-Pattern. Dann gibt es auch domänenspezifische Patterns, z. B. für Kontakte oder Transaktionen in der doppelten Buchführung. Das sind im Prinzip meist größere Entwurfsvorschläge, aus denen man sich dann was rauspicken kann.

sitzt man dann da und denkt sich "ahh, hier nutze ich jetzt das Pattern xyz weil ... " und "macht das dann einfach"?

Jein. Wenn ich ein komplexes Objekt erzeugen muss, und ich eine fluent API haben möchte, bietet sich ein Builder an. Wenn ich ereignisgesteuert etwas machen muss, baue ich einen Observer. Das sind so Dinge, da überlegt man nicht groß. Habe ich allerdings ein kniffligeres Problem mit dem Entwurf, kann es schon sein, dass ich schaue, ob es dafür nicht ein Pattern gibt oder ich mir von einem Pattern etwas Inspiration hole.

 

[KonradN]

Ich sehe Pattern als eine Art solide Methoden eines Handwerks an. Das schadet nicht, diese zu kennen, alleine schon um das Wording zu kennen.

Aber es ist in meinen Augen nicht das Mittel, um objektorientierte Entwicklung zu lernen. Das ist das, was ich aber immer oft sehe: Man hat Java Grundlagen gelernt - dann kommen DIe Entwurfsmuster von Kopf bis Fuß. Aber die objektorientierte Denkweise bekommt man damit nicht.

Das ist wie im Handwerk: Du hast gelernt, wie man Holz verbinden kann. Du kannst da mit Nägeln und Schrauben arbeiten. Es gibt diverse Metalwinkel. Und dann gibt es viele weitere Möglichkeiten wie Zapfverbindungen und und und ...

Das ist toll, aber nun bau etwas! Ups - da fehlt etwas. Das ganze Bild muss da sein! Wieso und warum irgend etwas gemacht wird.

Ich habe damals das Buch "Object Thinking" gelesen. Das fand ich sehr hilfreich und gut. Pattern sind also nur ein kleiner Teil. Ja, es hilft total. Aber wenn man das nicht richtig verstanden hat, worum es genau geht, der hat da dann massive Probleme.

 

[weihnachtspyramide]

Wo, wie (oft) und wie bewusst begegnen euch diese ganzen GoF-Pattern im Berufsalltag?

Wenn man vernünftig programmiert, braucht man diese kacke eigentlich nicht.^^

 

[KonradN]

Wenn man vernünftig programmiert, braucht man diese kacke eigentlich nicht.^^

Das sehe ich komplett anders: Wenn man vernünftig programmiert, dann setzt man diese eigentlich immer um. Ob man dies umsetzt, weil man das Pattern anwendet oder ob man das einfach so macht, weil es halt Sinn macht, ist dabei egal: Das Pattern wurde umgesetzt.

 

[weihnachtspyramide]

Das sehe ich komplett anders: Wenn man vernünftig programmiert, dann setzt man diese eigentlich immer um. Ob man dies umsetzt, weil man das Pattern anwendet oder ob man das einfach so macht, weil es halt Sinn macht, ist dabei egal: Das Pattern wurde umgesetzt.

Viele der Pattern werden bereits implizit vom Java-Framework umgesetzt, man selber braucht da nicht viel zu machen. Ich halte eine Fixierung und zwanghafte Anwendung ebenjener für falsch.

 

[KonradN]

Viele der Pattern werden bereits implizit vom Java-Framework umgesetzt, man selber braucht da nicht viel zu machen. Ich halte eine Fixierung und zwanghafte Anwendung ebenjener für falsch.

Es geht ja nicht um das Framework sondern darum, eigene Dinge zu schreiben. Wenn ich über Software Entwicklung rede, dann habe ich definitiv nicht das kleine Hello World Programm im Kopf.

Projekte einer bestimmten Größe sind nur gut strukturiert möglich. Ob man da nun von "Pattern" redet oder nicht - unter dem Strich wird es auf eben genau diese Dinge hinaus laufen. Es geht nicht darum, ein spezifisches Pattern zu erzwingen. Erzwungen wird ein sauberer, wartbarer Code und dazu gehört eine gute Gliederung.

Es ist toll, dass Du keine Zwanghafte Anwendung von Holzverbindungen haben willst. Aber sobald es zu einer Verbindung von Hölzern geht, wirst Du zwangsläufig eben auf die üblichen Verbindungen zurück greifen. Und da ist dann auch das Wording wichtig. Der Meister kann dem Lehrling sagen: Nimm einen Stahlwinkel und Schrauben und verbinde damit die Hölzer. Daher werden verschiedene Methoden gelernt und man kann dies dann mit wenigen Worten klar bestimmen. Und dabei ist es egal, ob Du es als "Holzverbindungs-Pattern" betrachtest oder als "Der Typ im Baumarkt hat mir die Schrauben und die Winkel in die Hand gedrückt ... und dann habe ich die Holzverbindung hergestellt (und womöglich die Schrauben mit einem Hammer eingeschlagen. Abweichungen vom "Pattern" dürfen ja sein.)

So kann in einem Team recht einfach das Wording der Pattern verwendet werden. Wenn das Observer Pattern zum Einsatz kommen soll, dann ist schnell klar, was da gemeint ist. Pattern helfen daher also, die Kommunikation zu vereinfachen. Und gerade am Anfang kann es ein gutes Handwerkszeug sein, damit man z.B. Schrauben nicht mit dem Hammer einschlägt.

 

[weihnachtspyramide]

Es ist toll, dass Du keine Zwanghafte Anwendung von Holzverbindungen haben willst.

Softwareentwicklung hat nichts mit Holzverbindungen zu tun. Die Analogie ist falsch.

Ich erwarte nicht unbedingt einen Kommentar auf eine Antwort von mir... Geht es noch um das Thema? Und nur darum, möglichst viele Zeichen zu schreiben?

 

[KonradN]

Softwareentwicklung hat nichts mit Holzverbindungen zu tun. Die Analogie ist falsch.

Muss man jetzt schon einfache Vergleiche erklären?

Software Entwicklung ist aus meiner Sicht nun einmal auch nur ein Handwerk und da gibt es Arbeitsmaterialien und diverse handwerkliche Vorgehensweisen. So gesehen ist die Analogie eben doch nicht falsch.

Ich erwarte nicht unbedingt einen Kommentar auf eine Antwort von mir...

Wenn Du etwas schreibst, das aus meiner Sicht schlicht falsch ist, dann bekommst Du eine Antwort. So einfach ist das.

Geht es noch um das Thema? Und nur darum, möglichst viele Zeichen zu schreiben?

Ein typischer Tobias. Will der kleine Tobias wieder aus dem Bällespieleparadies abgeholt werden?

Aber ich denke, ich sehe das Problem: der Account ist jetzt schon eine Woche alt - da wird es wieder Zeit, einen neuen zu erstellen?

 

[weihnachtspyramide]

schlicht falsch ist,

Was war denn falsch? Inhaltlich war meine Antwort doch ähnlich zu der von mihe7. Gof-Pattern sind nicht alles...

 

[Wuast]

Ist es zufällig "Entwurfsmuster von Kopf bis Fuß"? Wenn nicht, solltest du dieses Buch gegen jenes eintauschen. Danach ergeben Entwurfsmuster für dich auf jeden Fall sehr viel Sinn und ich behaupte mal, daß du danach der Meinung sein wirst, OOP vorher noch nicht richtig verstanden zu haben.

Nein, leider nicht. Es ist "Grundkurs Software-Engineering mit UML" und die Lektüre ist vorgegeben Alles andere darf ich natürlich zusätzlich noch heranziehen, sollte aber eigentlich nicht nötig sein. Ich habe aber einen ganz wunderbaren YT-Kanal dazu gefunden, damit werde ich mir die anschauen und jeweils ein eigenes Beispiel nachbauen.

[Zusatz] Muster können auch aufeinander zugreifen: https://javarevisited.blogspot.com/...ava-programmers-developers.html#axzz7m0BdfcUX

Ich wein gleich Spaß beiseite, danke für die Antwort. Das macht zumindest etwas Mut, dass man auch ohne die Perfektionalisierung aller GoF's "nützlich" sein kann.

Es ist auch gefährlich sich zu sehr auf Patterns zu versteifen. Es sind Lösungen/Werkzeuge für bestimmte Probleme und passen nicht immer. Die Methode "Welches Pattern könnte ich den jetzt noch anwenden" ist oft nicht zielführend.
(...) Und das geht einem sukzessive in Fleisch und Blut über. Ich könnte dir aber auch nicht alle im Detail erklären.

Das erleichtert mich etwas

Aber wenn man das nicht richtig verstanden hat, worum es genau geht, der hat da dann massive Probleme.

bezieht sich das jetzt auf die OO allgemein oder speziell hinsichtlich eines Projektes, wo man darüber nachdenkt ein bestimmtes Pattern anwenden zu können oder auch nicht?
Grundsätzlich sehe ich das als Anfänger auch immer wieder bei mir selbst: Ich wurschtle hier und da und verliere dann irgendwann den Überblick und habe das Gefühl, ich komm nicht mehr weiter. Das ich jetzt irgendwann mal gelernt habe, was ein Interface ist hilft mir aber irgendwie in der Praxis nicht weiter, weil das Gefühl fehlt, wann ich das nutzen kann (vllt. ein blödes Bsp. weil ich glaube, das habe ich wenigstens ein kleines bisschen verstanden inzwischen aber trotzdem ^^)

Wenn man vernünftig programmiert, braucht man diese kacke eigentlich nicht.^^

Womit eine Zündschnur entfacht wurde.. Vllt. kannst du das etwas ausführen, warum du das für falsch hältst? Oder geht es speziell um die "Fixierung" darauf?
In dem mir vorliegen Buch heißt es, wer die Patterns nicht schnallt und anwenden kann, sollte kein Entwickler werden. (plakativ und oberflächlich wiedergegeben).

 

[KonradN]

Was war denn falsch? Inhaltlich war meine Antwort doch ähnlich zu der von mihe7. Gof-Pattern sind nicht alles...

Nein, das war es eben nicht. Deine Aussage in #8 war nicht die Aussage von @mihe7 und aus meiner Sicht nicht einmal ähnlich. Daher meine Erwiderung in #9. Kannst Du ja einfach noch einmal ansehen.

 

[mrBrown]

Vllt. kannst du das etwas ausführen, warum du das für falsch hältst?

Weil er gerne trollt, einfach ignorieren

 

[mrBrown]

Im Endeffekt ist der Compiler (Interpreter, Transpiler,...) die entscheidende Instanz was formell korrekten Code angeht WIE dieser zustande kommt ist dieser Software eher egal. Die (Nicht)Anwendung von Mustern (i.S.v. Lösungswegen) spricht nicht für oder gegen die Professionalität der jeweiligen SW-Lösung.

@thecain hats ja schon gesagt, Code schreibt man vor allem auch für andere Menschen nicht nur für Compiler - und daran würde ich durchaus auch Professionalität festmachen, es eben nicht nur „irgendwie“ zu machen, sondern sauber und mit etablierten Methoden.

 

[KonradN]

bezieht sich das jetzt auf die OO allgemein oder speziell hinsichtlich eines Projektes, wo man darüber nachdenkt ein bestimmtes Pattern anwenden zu können oder auch nicht?
Grundsätzlich sehe ich das als Anfänger auch immer wieder bei mir selbst: Ich wurschtle hier und da und verliere dann irgendwann den Überblick und habe das Gefühl, ich komm nicht mehr weiter. Das ich jetzt irgendwann mal gelernt habe, was ein Interface ist hilft mir aber irgendwie in der Praxis nicht weiter, weil das Gefühl fehlt, wann ich das nutzen kann (vllt. ein blödes Bsp. weil ich glaube, das habe ich wenigstens ein kleines bisschen verstanden inzwischen aber trotzdem ^^)

Das betrifft beides. Man muss versuchen, einen generellen Überblick zu bekommen. Das ist etwas, das aber mit der Zeit von alleine kommt.

Bei einem spezifischen Projekt ist es dann sehr wichtig, dass man sich hier überlegt, was man genau braucht. Wie will man etwas abbilden, so dass die Anforderungen erfüllt werden. Da geht es eben nicht darum, dass man ein Pattern nimmt und sich sagt: Das verwende ich jetzt - egal ob es passt oder nicht.
Die Pattern sehe ich da eher als Hilfe. Du willst ein Ziel erreichen und musst jetzt überlegen, wie Du das hin kriegen kannst. Das kann man sich dann selbst überlegen. (Das war lange in einem Team, in dem ich war, so. Pattern wurden da sogar mehr oder weniger abgelehnt! Es ging um das eigentliche Problem und das wurde dann sinnvoll gelöst.)
Aber gerade am Anfang kann es schwer sein, da die richtigen Ideen zu entwickeln. Da kann es helfen, wenn man ein paar "Patentrezepte" zur Hand hat. Dann erkennst Du Ähnlichkeiten und das kann Dir dann helfen, für das konkrete Problem ein Lösung zu finden.

Bei den Pattern geht es also nur um eine Art Vorlage. So und so kann man dieses oder jenes machen. Wenn Du nun sowas umsetzen willst, dann musst Du dem nicht komplett folgen.

Womit eine Zündschnur entfacht wurde.. Vllt. kannst du das etwas ausführen, warum du das für falsch hältst? Oder geht es speziell um die "Fixierung" darauf?
In dem mir vorliegen Buch heißt es, wer die Patterns nicht schnallt und anwenden kann, sollte kein Entwickler werden. (plakativ und oberflächlich wiedergegeben).

Nein, ich sehe da keine Zündschnur. Ein User hat eine wenig durchdachte Sicht. Argumente kommen da leider erfahrungsgemäß nicht.

Ich vermute, dass die Sichtweise einfach ist, dass man diese Herangehensweise über Pattern nicht notwendig ist. Man kann auch durchaus ohne Pattern vernünftig programmieren. Aber dann kommt man am Ende dennoch wieder zu den Pattern. Wenn ein Objekt an Veränderungen eines anderen interessiert ist, dann ist es nun einmal das Observer Pattern. Aber du kannst heran gehen:
a) Du analysierst, was da gebraucht wird. Dann findest Du eine Lösung und implementierst es. Du hast von Observer Pattern womöglich nie etwas gehört. Aber wenn Du es vernünftig gemacht hast, dann wird wohl ein Observer Pattern umgesetzt worden sein.
b) Du gehst hin und erkennst: Bei dem Problem wäre das Observer Pattern eine Lösung. Ich mache das Observer Pattern. Dann brauche ich paar Interfaces und und und ... Du setzt also strikt etwas 1:1 um. Das ist Kacke (um da eine Wortwahl eines Vorredners zu benutzen). Man sollte das Pattern so verstanden haben, dass man es sinnvoll implementiert ... ggf. mit gewissen Abweichungen.

Daher kann es eine gute Hilfe sein, um gewisse Dinge zu lernen. Es gibt bessere Wege (aus meiner Sicht). Das Beste ist ein erfahrener Senior oder Lead Entwickler, der als Mentor auftritt. Da lernst Du keine Pattern. Da machst Du Analysen eines Problems mit entsprechender Umsetzung. Er wird dir dann Pattern zeigen. Aber nicht als "Das ist jetzt das Observer Pattern". Sondern er wird eine Lösung für ein Problem aufzeigen und diese etwas erläutern. Sowas findet sich aber sehr selten.

Bei sowas nenne ich übrigens auch das Pattern. Dann kann man das noch nachlesen. Und es ist leichter zu sagen: "Erinnerst Du Dich an das Observer Pattern?" als zu sagen: "Erinnerst Du Dich noch an Projekt abc - wie wir das Problem xyz gelöst haben?"

Pattern sind also sehr nützlich. Alleine schon für eine gemeinsame Sprache können die Pattern wichtig sein. Das funktioniert aber nur, wenn ich ein Pattern nennen kann ohne dass mich das Team mit großen Augen anschaut und sicht fragt, von welchem Bahnhof ich gerade rede ....

 

[Wuast]

Ja, verstehe.
Ich glaube, am Anfang ist vor allem das

Das betrifft beides. Man muss versuchen, einen generellen Überblick zu bekommen. Das ist etwas, das aber mit der Zeit von alleine kommt.

Bei einem spezifischen Projekt ist es dann sehr wichtig, dass man sich hier überlegt, was man genau braucht. (...) Du willst ein Ziel erreichen und musst jetzt überlegen, wie Du das hin kriegen kannst. Das kann man sich dann selbst überlegen. (...)
Aber gerade am Anfang kann es schwer sein, da die richtigen Ideen zu entwickeln. Da kann es helfen, wenn man ein paar "Patentrezepte" zur Hand hat.

das Problem: Ich muss ja alle Pattern verstanden und verinnerlicht haben, um überhaupt zu merken: Ahh, hier habe ich XYZ als Problem erkannt. Da gibt es das Pattern ABC, das könnte helfen.

Vllt. hat mich auch das Kapitel über 30 Seiten erstmal erschlagen, ich baue die Pattern jetzt alle nach und nach mal auf und hoffe, dass ich dann ein besseres Gefühl kriege.

Mentorin ist immer klasse. Im Forum gibt es da glücklicherweise schon eine gnädige Seele, die sich sehr dankenswerterweise meiner immer wieder erbarmt.
Ein Mentor face-to-face wäre natürlich noch besser Die Idee passt aber leider kaum in die Leistungsgesellschaft rein - da werden ja nur Experten gesucht.

Lieben Dank an alle.

 

[yfons123]

also eigentlich kannte ich bisher "nur" Singleton, Observer, Factory)

in c# ist es so dass manche dieser pattern komplett in vergessenheit geraten sind da sie c# in die sprache eingebaut hat ohne dass man es mitkriegt

zb in c# ist das builder pattern nutzlos da du den "Property Initializer" hast und auch noch default parameter ( haben andere sprachen auch wie php )
java hat halt keine default parameter also muss man sich mit dem pattern behelfen um auf das selbe resultat zu kommen

 

[White_Fox]

Grundsätzlich sehe ich das als Anfänger auch immer wieder bei mir selbst: Ich wurschtle hier und da und verliere dann irgendwann den Überblick und habe das Gefühl, ich komm nicht mehr weiter. Das ich jetzt irgendwann mal gelernt habe, was ein Interface ist hilft mir aber irgendwie in der Praxis nicht weiter, weil das Gefühl fehlt, wann ich das nutzen kann (vllt. ein blödes Bsp. weil ich glaube, das habe ich wenigstens ein kleines bisschen verstanden inzwischen aber trotzdem ^^)

Ich habe ja, wie gesagt, vom Programmieren keine Ahnung. Ich bin E-Techniker, und wir haben im Studium auch etwas Programmieren gelernt, zwei Semester C, und später ein Semester Java. In der Java-Vorlesung hat unser Prof alles darauf verwendet daß möglichst viele verstehen, was eine Klasse und was ein Objekt ist.
Ich selber habe das zwar irgendwann verstanden und später auch wieder aufgefrischt, habe Klassen aber bis dato lediglich als eine Art höherer Datentyp gesehen. Man kann da lauter Variablen reinpacken, pappt Getter- und Settermethoden dran, schön und gut. Was ein Interface macht, ok, aber wozu man das braucht?

Und für ein kleines eigenes Softwareprojekt habe ich mir dann mal besagtes Buch oben durchgeschmökert und das erste Mal so eine Ahnung davon bekommen, was der Unterschied zwischen Informatik und Programmierung ist. Vielleicht wechselst du das Buch wirklich mal und liest das vorgegebene Buch danach quer um zu schauen, was noch fehlt. Ich bin mir recht sicher, daß du die Klausur so gut bestehen wirst.

 

[mihe7]

Ich halte eine Fixierung und zwanghafte Anwendung ebenjener für falsch.

Der Aussage würde ich sogar insofern zustimmen, als dass es falsch ist, ein Pattern einzusetzen, bloß damit man ein Pattern eingesetzt hat.

 

[yfons123]

was man aber auch erst im nachhinein realisiert ... " joa das war blödsinn das da zu machen"

vorallem in game dev wo Singleton der König aller Patterns ist und dann leute kommen und sagen "joa... jetzt ist das halbe game static und irgendwo hängts"

 

[mihe7]

was man aber auch erst im nachhinein realisiert ... " joa das war blödsinn das da zu machen"

Das geht zwar in die Richtung aber ich meinte das noch drastischer. Es soll ja Leute geben, die explizit danach suchen, wo sie denn noch irgendein Pattern unterbringen könnten. Die Idee dahinter scheint wohl zu sein, dass viele Patterns guten Code machen. Das ist ungefähr so, als ob ich bei jeder for-Schleife einen Visitor einbaue.

 

[yfons123]

Das ist ungefähr so, als ob ich bei jeder for-Schleife einen Visitor einbaue.

oder mit gewalt streams bzw in c# Linq hernehme

 

[KonradN]

Das geht zwar in die Richtung aber ich meinte das noch drastischer. Es soll ja Leute geben, die explizit danach suchen, wo sie denn noch irgendein Pattern unterbringen könnten.

War das FizzBuzz Enterprise oder so? Da gab es doch ein GitHub Repository….

Edit: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

 

[Wuast]

Ich habe ja, wie gesagt, vom Programmieren keine Ahnung. Ich bin E-Techniker, und wir haben im Studium auch etwas Programmieren gelernt, zwei Semester C, und später ein Semester Java. In der Java-Vorlesung hat unser Prof alles darauf verwendet daß möglichst viele verstehen, was eine Klasse und was ein Objekt ist.
Ich selber habe das zwar irgendwann verstanden und später auch wieder aufgefrischt, habe Klassen aber bis dato lediglich als eine Art höherer Datentyp gesehen. Man kann da lauter Variablen reinpacken, pappt Getter- und Settermethoden dran, schön und gut. Was ein Interface macht, ok, aber wozu man das braucht?

Und für ein kleines eigenes Softwareprojekt habe ich mir dann mal besagtes Buch oben durchgeschmökert und das erste Mal so eine Ahnung davon bekommen, was der Unterschied zwischen Informatik und Programmierung ist. Vielleicht wechselst du das Buch wirklich mal und liest das vorgegebene Buch danach quer um zu schauen, was noch fehlt. Ich bin mir recht sicher, daß du die Klausur so gut bestehen wirst.

Ich danke dir für den Hinweis. Ich werd mal nach dem Buch schauen. Klausur bleibt mir zum Glück erspart

EDIT: @White_Fox , ich wollte dir eigentlich gerade mal eine PM schicken wg. der Buchempfehlung, darf ich aber nicht. Wieso? Umgekehrt vllt?

 

[Wuast]

War das FizzBuzz Enterprise oder so? Da gab es doch ein GitHub Repository….

Edit: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

ähm.. ich hab da mal drauf geklickt und nur mal ganz kurz überflogen. Bisher habe ich mich mit GitHub nicht auseinander gesetzt, also kann ich jetzt nicht viel dazu sagen. Aber was soll dieses FizzBuzz spiel für Vorstellungsgespräche sein? Habe ich da jetzt irgendwas nicht gecheckt oder soll das wirklich etwas aussagen? ich mein Satire, okay.. aber wozu?

 

[yfons123]

ber was soll dieses FizzBuzz spiel für Vorstellungsgespräche sein? Habe ich da jetzt irgendwas nicht gecheckt oder soll das wirklich etwas aussagen? ich mein Satire, okay.. aber wozu?

dieses fizz buzz zeigt dir wie man mit "enterprise code quality" auch alles übertreiben kann

es ist ein ganz simlpes spiel das mit maximal viel design und patterns voll gepumpt wurde

 

[KonradN]

FizzBuzz ist ein einfaches Spiel, das man relativ einfach programmieren kann. So wird dies oft als Beispiel genommen - bestes Beispiel ist as TDD Beitrag: https://www.java-forum.org/thema/test-driven-development-anhand-von-fizzbuzz.189510/

Dort wurde dann aber krampfhaft alles hinein gepackt - also sozusagen Pattern auf Zwang umgesetzt.

 

[Wuast]

Okäse, dann machst ja "Sinn"

 

[KonradN]

Evtl. macht es Sinn, dass alles noch etwas auszuführen.

Bei der Software Entwicklung - speziell bei TDD - ist das oberste Prinzip: Keep It Simple, Stupid (KISS). Du machst nichts, was nicht notwendig ist! Und Du versuchst, alles einfach umzusetzen.

Alles Andere kommt dann im Nachgang. Nach dem schreiben des nicht funktionierenden Tests und dem dann lauffähig machen folgt die Refactoring Phase. Da kommen dann teilweise Pattern erst ins Spiel. Da wird dann optimiert (Stimmt nicht ganz, denn das findet teilweise schon bei dem Aufteilen der Features in Tasks statt, denn da fließt schon einiges an objektorientiertes Design ein). Dadurch kann eigentlich nicht vorkommen, dass man ein Pattern umsetzt, das so keinen Sinn macht. (Wichtig: Nur, weil es im "Nachgang" kommt, ist das nicht unwichtiger oder so. Also SOLID Principles werden eingehalten und was es da sonst so für Regeln gibt. Das ist also keine Gewichtung sondern eine zeitliche Reihenfolge.)

Kann man sich ja überlegen:

• Beim Erstellen der einzelnen Tasks ist man komplett auf das Feature beschränkt. Da ist es also noch relativ oberflächig und es gibt in erster Linie eine grobe Vorstellung, was wie zu tun ist.
• Bei der Implementation der Tasks hat man dann sowas meist in Form von Refactorings und da stellt man nur existierendes um.

Klar, Ausnahmen mag es geben. Aber dann ist es meiner Meinung nach nicht mehr das 100% klassische TDD.

Oder habe ich da jetzt eine falsche Sicht drauf? @mrBrown? @mihe7?

 

[M.L.]

Interface

Der Einsatz eines Interface kann Sinn machen, wenn bei einem Teil der Software ein hoher Änderungsgrad zu erwarten ist oder man sich nicht mit im Detail mit dem Verhalten der Software auskennen will/muss/...(z.B. Parametern einer DB-Anbindung)
Klassen (engl. Zitat aus diesem Twitter Thread): "A class is a user-defined blueprint or prototype from which objects are created. Classes provide a means of bundling data and functionality together." (Es kann Sinn machen Daten und sie betreffende Methoden in passende Klassen zu setzen)

 

[Wuast]

Evtl. macht es Sinn, dass alles noch etwas auszuführen.

Bei der Software Entwicklung - speziell bei TDD - ist das oberste Prinzip: Keep It Simple, Stupid (KISS). Du machst nichts, was nicht notwendig ist! Und Du versuchst, alles einfach umzusetzen.

Alles Andere kommt dann im Nachgang.

ich hatte das jetzt erstmal so verstanden, dass die Patterns eine gute Architektur ermöglichen können (sollen) und deswegen auch das Programm einfacher wird.
also deiner Erfahrung nach wird's in der Praxis erstmal irgendwie schmucklos hingewurschtelt und wenn man den Kern getroffen hat, dann wird sauber gemacht und aufgeräumt? mal ganz blöd ausgedrückt

 

[White_Fox]

EDIT: @White_Fox , ich wollte dir eigentlich gerade mal eine PM schicken wg. der Buchempfehlung, darf ich aber nicht. Wieso? Umgekehrt vllt?

Merkwürdig...ich wüßte nicht daß ich PM-Empfang mal deaktiviert hätte. Der Titel sollte eigentlich reichen, ansonsten ist es das hier:

Amazon.de

Das Buch mag erst etwas albern wirken, aber ich kann dir versichern daß man es auch gut vorm Zubettgehen lesen kann. Ich selber habe es normalerweise immer beim S-Bahnfahren durchgelesen.

 

[KonradN]

ich hatte das jetzt erstmal so verstanden, dass die Patterns eine gute Architektur ermöglichen können (sollen) und deswegen auch das Programm einfacher wird.

Entwurfsmuster sind (nach Wikipedia) "bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme". Ob eine Architektur gut oder schlecht ist, ist davon erst einmal unabhängig. Da sind andere Kriterien wichtiger (Das was Du da u.a. angedeutet hast - das Programm wird "einfacher"). Wenn man ein Entwurfsproblem hat, das durch so eine Lösungsschablone gelöst werden kann, dann ist in der Regel eine akzeptierte Lösung. Das heisst aber z.B. nicht, dass es die beste Lösung ist.

also deiner Erfahrung nach wird's in der Praxis erstmal irgendwie schmucklos hingewurschtelt und wenn man den Kern getroffen hat, dann wird sauber gemacht und aufgeräumt? mal ganz blöd ausgedrückt

Wenn man nach Test Driven Development (TDD) vorgeht, dann ist die erste Lösung tatsächlich so. Hast Du Dir den verlinkten Thread einmal angesehen? Dort wird es ja von @mrBrown vorgestellt. Man könnte das Vorgehen dort ggf. unter den Gesichtspunkten analysieren bzw. ich könnte meine Sichtweise an Hand des beschriebenen Vorgehens etwas erläutern. Denn da kommt auch ein erstes Design, ehe man anfängt zu entwickeln. Denn wie ich immer wieder hier im Forum schreibe: Vor dem Programmieren kommt immer erst ein Nachdenken, was man denn entwickeln will. Wie es funktioniert. Wie Dinge zusammen hängen. (Das fehlt bei diesem TDD Thread.)

In der Praxis ist TDD (leider) nicht ganz so relevant. Es ist teilweise erschreckend, was man so drußen an Projekten sieht. Selbst hier im Forum gibt es Leute, die Unit Test als Zeitverschwendung abtun. Oder der Verzicht auf jegliche Codeanalyse (Und ich erwarte da noch einiges mehr in Zukunft. Der neue Chatbot kann gewisse Probleme in Programmen erkennen und sogar erklären, wie man es verbessern sollte und wo das Problem ist). Ich habe daher ja so zwei GitHub Projekte mit Maven Projekten einmal pur Java und einmal JavaFX um da eine Grundlage für Anfänger zu bieten: Einfach kopieren und damit loslegen. Aber da weiche ich gerade vom Thema ab.

Clean Code ist ein wichtiges, großes Gebiet. In der Praxis kommt das viel zu kurz.

 

[Wuast]

Hast Du Dir den verlinkten Thread einmal angesehen? Dort wird es ja von @mrBrown vorgestellt.

ich habe es mal ganz flott und grob überflogen. Ich glaube, das Thema kommt ohnehin nochmal dran und ich kriege (u.a. von hier) gerade so viel Input, dass ich nicht mehr hinterherkomme.
Da der Thread ja sehr umfangreich ist, muss ich das vertagen.

Ich habe daher ja so zwei GitHub Projekte mit Maven Projekten einmal pur Java und einmal JavaFX um da eine Grundlage für Anfänger zu bieten: Einfach kopieren und damit loslegen. Aber da weiche ich gerade vom Thema ab.

Clean Code ist ein wichtiges, großes Gebiet. In der Praxis kommt das viel zu kurz.

Das habe ich wenn ich mich richtig erinnere deiner Signatur schon mal entnommen. Aber gleiches Ding wie oben: Aktuell zu viel auf einmal. Mein Tag bräuchte aktuell wirklich 72 Std...

 

[mihe7]

Oder habe ich da jetzt eine falsche Sicht drauf?

Ne. Im von Dir genannten Zusammenhang würde ich noch YAGNI nennen.

@Wuast YAGNI steht für You Ain't Gonna Need It, womit zum Ausdruck gebracht werden soll, dass man nichts umsetzen soll, was man nicht braucht. Das geht natürlich Hand in Hand mit KISS und bedeutet im Umkehrschluss aber auch, dass man wissen muss, was man braucht.

Um auf die GoF-Patterns zurückzukommen: das Buch beginnt auf Seite 1 mit den Worten "Designing object-oriented software is hard". Niemand schüttelt einen Entwurf aus dem Ärmel, der dann auch so bleibt. Die Probleme sind einfach zu komplex als dass man sie unmittelbar in allen Details überblicken könnte. Manchmal sitzt man vor einem Entwurfsproblem, das einen in die Verzweiflung treibt, weil jeder Ansatz, den man findet, irgendeinen Haken hat. Da können Patterns helfen, müssen aber nicht.

Zum Thema YAGNI findest Du auf S. 31 "Design patterns should not be applied indiscriminately: [...] A design pattern should only be applied when the flexibility it affords is actually needed." YAGNI, eben.

 

[mihe7]

Was ein Interface macht, ok, aber wozu man das braucht?

Du als E-Techniker hättest damit doch überhaupt kein Problem haben dürfen, bei Euch läuft doch alles über Interfaces. Das geht ja schon beim Strom, der bekanntermaßen aus der Steckdose kommt, los

 

[KonradN]

Was ein Interface macht, ok, aber wozu man das braucht?

Wenn @mihe7 da kurz drauf reagiert, dann will ich da auch einmal meinen Senf dazu abgeben. Denn Elektriker kennen das ja wirklich und nutzen es ständig.

Nur ein Beispiel: Du hast einen Generator - der erzeugt eine Spannung. Und einen Verbraucher - der will eine gewisse Spannung haben, damit dann ein Strom durch ihn fließen kann.

Alles kein Problem. Der Generator wird dann mit dem Verbrauche verbunden. Du hast also eine direkte Abhängigkeit: Klasse Generator kennt die Klasse Verbraucher. Und die Klasse Verbraucher kennt den Generator. Das funktioniert.

Aber nun willst Du den Verbraucher auch an anderen Generatoren anschließen. Und natürlich willst Du an den Generator auch andere Verbraucher anschließen können. Das machst Du dann über ein Interface. Man einigt sich auf ein sinnvolles Interface. Das kann dann z.B. beim Generator die Steckdose sein. Die findet sich dann (mit klarer Spezifikation) an vielen Stellen. Und beim Verbraucher hast Du dann ein Interface "Stecker". Und damit kannst Du dann beliebige Verbraucher an beliebige Steckdosen anschließen. Der Lampe ist es egal, ob ich diese an eine Steckdose in meinem Haus, an dden 12V/220V Wandler im Auto oder an den Benzingenerator hänge.
Und dem Benzingenerator ist es für seine Arbeit egal, ob ich da eine Lampe, ein Ladegerät oder einen Staubsauger anschließe (So die Spezifikation stimmt, also nicht mehr Leistung verlangt wird, als erlaubt).

Das Ganze hinkt jetzt nur an einer Stelle: In der Entwicklung hat man in der Regel eine einseitige Abhängigkeit. Ich biete also eine Steckdose. Da ist mir dann egal, wie Du darauf zugreifst. Du kannst da also einen Stecker nutzen aber wenn Du an Zimmermansnägel Drähte machst, dann kannst Du die auch rein stecken (Dumme Idee - bitte nicht machen!).

Aber das ist eigentlich alles - du abstrahierst und musst daher nicht mehr etwas konkretes kennen. Du kannst dann alles, was das Interface implementiert, nutzen.

Hat das etwas aufgezeigt, was das mit den Interfaces soll?

 

[Wuast]

Ne. Im von Dir genannten Zusammenhang würde ich noch YAGNI nennen.

@Wuast YAGNI steht für You Ain't Gonna Need It, womit zum Ausdruck gebracht werden soll, dass man nichts umsetzen soll, was man nicht braucht. Das geht natürlich Hand in Hand mit KISS und bedeutet im Umkehrschluss aber auch, dass man wissen muss, was man braucht.

Um auf die GoF-Patterns zurückzukommen: das Buch beginnt auf Seite 1 mit den Worten "Designing object-oriented software is hard". Niemand schüttelt einen Entwurf aus dem Ärmel, der dann auch so bleibt. Die Probleme sind einfach zu komplex als dass man sie unmittelbar in allen Details überblicken könnte. Manchmal sitzt man vor einem Entwurfsproblem, das einen in die Verzweiflung treibt, weil jeder Ansatz, den man findet, irgendeinen Haken hat. Da können Patterns helfen, müssen aber nicht.

Zum Thema YAGNI findest Du auf S. 31 "Design patterns should not be applied indiscriminately: [...] A design pattern should only be applied when the flexibility it affords is actually needed." YAGNI, eben.

YAGNI habe ich schon gelesen Genau mein Ding.

Das Buch, das whitefox empfohlen hat, habe ich mal bestellt. Auch der von mir erwähnte YT-Kanal-Mensch empfiehlt es sehr. Scheint ja DIE Lektüre dafür zu sein.

Ich werde hier einfach mal ab und an weiter GoF-bezogene Fragen stellen. Meine ersten beiden Mini-Projekte zu Strategy und Observer habe ich umgesetzt. Kurz zum Strategy: Habe ich Sinn und Unsinn von dem Pattern so richtig in 2 Sätzen zusammengefasst?
"Strategy-pattern belongs to the behavioral pattern. It is useful in cases where the algorithm needs to be potentially variable, so depending on the individual situation to the runtime another part of the code can be adressed and executed."

 

[White_Fox]

Hat das etwas aufgezeigt, was das mit den Interfaces soll?

Hätte mich, als ich auf dem damaligen Kenntnisstand war den ich beschrieben habe, leider nicht viel weitergebracht.

Du hast beschrieben was ein Interface macht, aber das wußte ich so, in dieser Form, damals bereits. Was ich nicht wußte, war, welche dollen Kniffe damit möglich sind und wie man sowas geschickt einsetzt. So richtig begriffen habe ich das erst, als ich mich selber mit dem Entwurfsmusterkram herumgeschlagen habe, das Beobachtermuster ist da m.E. deutlich besser als Anwendungsbeispiel geeignet gewesen.

Und mir selbst bewiesen, daß ich es tatsächlich begriffen hatte, hatte ich als ich selber meine MVC-Struktur für mein Projekt zusammengestöpselt habe. Das hat erst mit dem dritten Anlauf oder so richtig geklappt, und vom zweiten zum dritten Anlauf habe ich so >1.000 Codezeilen weggeworfen.

 

[mihe7]

Habe ich Sinn und Unsinn von dem Pattern so richtig in 2 Sätzen zusammengefasst?

Finde ich völlig in Ordnung. Algorithmen in Objekten mit einheitlicher Schnittstelle kapseln, um sie austauschen zu können -> Strategy.

 

[KonradN]

Naja, 40 % deiner Beiträge sind falsch. Bei @yfons123 sind es schon 90. Wollen wir uns deshalb streiten?

Wenn das so wäre, dann könntest du ja Argumente bringen. Aber du hast keine Argumente. Du ignorierst Fakten und drehst Dir alles irgendwie zurecht. Dazu ein mangelhaftes Textverständnis ….

Da lohnt sich eine Argumentation mit Dir nicht.

Nur weil eine zwanghafte Anwendung von Pattern nicht gut ist, bedeutet dies z.B. nicht, dass jeder Einsatz schlecht ist. Dass es eben doch gut sein kann, die Pattern zu kennen, sieht man in der Praxis übrigens sehr gut. Daher wird dies in der Ausbildung in vielen Bereichen eingesetzt.

Aber ich sage einfach einem winke winke …. Der Account wird keine Woche alt ….

 

[LimDul]

Um noch mal eine Meinung dazu zu sagen
Pattern sind Werkzeuge. So wie ein Schraubenzieher und Hammer bei einem Handwerker. Ich brauche sie nicht unbedingt um guten Code zu schreiben. Und auch ein Handwerker kann einen Nagel mit einem Stück Holz einschlagen anstelle eines Hammers.

Aber sie erfüllen mehrere Dinge:
* Klare Kommunikation. Kommunikation ist immer ein Problem in der Softwareentwicklung. Anforderungen kommen oft von komplett it-fernen Leuten, die gerade mal einen PC ein/ausschalten können und müssen am Ende von - überspitzt formuliert - Nerds umgesetzt werden, die in 0en und 1en denken. Jede Stelle an der man die Kommunikation klarer und eineindeutiger gestalten kann, sorgt dafür dass das Stück Software am Ende besser wird und man nicht die berühmte Schaukel am Baum baut (Siehe: https://www.programmwechsel.de/lustig/management/schaukel-baum.html). Und genauso wie ein Lehrling es versteht, wenn ein Meister im sagt "Nutz den Hammer dafür den Nagel einzuschlagen" Sollte ein Software-Entwickler verstehen, wenn im Ticket steht "Setz es als Observer Pattern um".
Man muss als Junior-Entwicklung es jetzt nicht aus dem Ärmel schütteln können. Wissen ist auch oft Wissen wo es steht. Man sollte aber mindestens in Lage sein mittels google oder Bücher das dann bei Bedarf nachschlagen zu können.

* Standardlösungen für Standard-Probleme - schnellere Entwicklung
Mit steigender Erfahrung sieht man häufiger, was eine Standardlösung für manche Probleme ist und muss die nicht mehr selber sich ausdenken. Man wird dadurch schneller, weil man mit der Zeit ein Baukasten hat, aus dem man Lösungen rausziehen kann. Der Baukasten wächst mit der Zeit (Genauso wie ein Handerker vermutlich deutlich mehr Spezialwerkzeuge hat als der Hobby-Schreiner).


Das Risiko ist - und das wurde hier auch von allen adressiert - ist natürlich das folgende Sprichwort: "Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel". Sprich, das man Pattern auf jedes Problem anwendet egal ob passend oder nicht. Deswegen ist bei der Softwareentwicklung es wichtig, dass Junior Entwickler begleitet werden und ein "Training on the job" erhalten. Das ist leider im Projektstress nicht immer einfach, aber essentiell das man lernt. Und da können natürlich Vorgehensweisen wie Test Driven Development helfen - die Schritte sind da so klein, dass ein unpassendes Pattern einfach extrem viel Aufwand verursacht.

Aber Pattern sind essentiell wichtig - vor allem das man sie in Grundzügen kennt, weniger dass man sofort weiß wo man sie anwendet.

 

[Neumi5694]

Na ja, das hängt maßgeblich damit zusammen, wann der erste Moderator wach wird, also @mrBrown . So lange musst du meine Anwesenheit noch ertragen, danach kannst du weiter ungestört Müll schreiben.

Ich dachte, Moderatoren dürfen nur am 7. Tag schlafen?

Für den weniger erfahrenen Programmierer sind selbst umzusetzende Patterns gut zur Orientierung, eben "Muster". Man kann sich strikt daran halten oder auch eben nicht, die bleiben ja nicht über jahrzehnte gleich (bis auf wenige Ausnahmen). Würde niemand was Neues probieren, dann gäb's auch keine neuen.

Wer schon länger in der Materie drin ist, hat längst rausgefunden, was für ihn funktioniert und was nicht. Und auch wenn dann mal ein (Online-) Magazin irgend ein neues bahnbrechendes Pattern vorstellt, muss man sich nicht dran halten. Man probiere es mal aus, schaue, ob man damit klarkommt und entscheide dann.

 

[mihe7]

Endlich wieder 🍿

 

[mihe7]

wie ein Schraubenzieher und Hammer bei einem Handwerker. Ich brauche sie nicht unbedingt um guten Code zu schreiben.

Da kann ich nicht mitreden, ich tippe eher selten mit Hammer und Schraubenzieher und die Handwerker haben mir auch nicht geholfen. Der Fachkräftemangel macht es einem nicht leicht, heutzutage gutes Personal zu finden.

 

[LimDul]

A fool with a tool is still a fool