Pflichtenheft softwareentwicklung Muster

Wie im vorherigen Muster lautet die Antwort «nichts». Wie in, «einfach weiter machen, was Sie wahrscheinlich getan haben, und die Dinge werden in Ordnung sein.» Gute alte Action und Func können sich um die meisten Ihrer Bedürfnisse kümmern. Designmuster scheinen ein kontroverses Thema zu sein. Auf der einen Seite scheinen viele Entwickler sie zu lieben und das berühmte Buch der Viererbande wie heilige Schrift zu behandeln. Auf der anderen Seite lehnen viele Entwickler die Idee von Designmustern ab. Es ist nicht allzu schwer, Beiträge im Internet mit Titeln wie «Design Patterns are Bad Design», «Following Design Patterns Is A Bad Idea» und natürlich die unvermeidlichen «Design Patterns Considered Harmful» zu finden. Carlos Schults ist ein .NET Softwareentwickler mit Erfahrung in der Desktop- und Web-Entwicklung, und er versucht sich jetzt an Mobilgeräten. Er hat eine Leidenschaft für das Schreiben von sauberem und präzisem Code, und er interessiert sich für Praktiken, die Ihnen helfen, die App-Integrität zu verbessern, wie Codeüberprüfung, automatisierte Tests und kontinuierliche Erstellung. Mehr von Carlos lesen Sie auf carlosschults.net.

Eine zusammengesetzte Spezifikation kann zur Entwurfszeit für Fälle erstellt werden, in denen die Regeln im Voraus bekannt sind. Es vereinfacht die Dinge ein wenig, während immer noch alle Vorteile des Musters zur Verfügung gestellt. Viele Anwendungsfälle fallen in diese Kategorie. Dies war ein langer Beitrag, aber ich hoffe, es war eine hilfreiche Einführung in das Spezifikationsmuster. Es ist ein leistungsstarkes Muster für die Modellierung und Bewertung komplexer Regeln, das einen langen Weg zur Minimierung der Komplexität bei der Anwendung auf einen geeigneten Anwendungsfall ist. Wenn eine oder mehrere meiner Behauptungen oben wahr klingen, fragen Sie sich vielleicht, was mein Problem mit dem schlechten alten Spezifikationsmuster ist. Die Gründe sind vielfältig, aber wenn ich sie in einem Satz zusammenfassen würde, wäre es dieser: Das Spezifikationsmuster ist eine verherrlichte «if»-Anweisung. Ich habe das Gefühl, dass dieses Muster einfach nicht viel tut, um seine Existenz zu rechtfertigen.

Werfen Sie einen Blick auf das folgende Beispiel, das ein Codebeispiel aus dem Wikipedia-Artikel über das Muster ist: Sie verwenden dieses Muster jedes Mal, wenn Sie eine foreach-Schleife verwenden. Sehen wir uns ein wenig Code an. Als nächstes haben wir eine abstrakte Klasse CompositeSpecification, die die Basisklasse für alle Zweigknoten (nicht-Blatt) in unserer zusammengesetzten Spezifikation sein wird: Ich glaube nicht, dass ich sagen würde, iterator oder Command haben «schlecht gealtert», so viel wie sie jetzt «gelöste Probleme» sind — Sie müssen sie nicht implementieren, weil jemand die harte Arbeit für Sie bereits getan hat. In der Tat würde ich sagen, dass der Iterator jetzt relevanter als je zuvor ist, da «Yield Return» das Muster ganz einfach umsetzen lässt. Gemäß dem Spezifikationspapier von Eric Evans und Martin Fowler ist das Spezifikationsmuster ein Software-Designmuster, das angewendet werden kann, um Geschäftsregeln zu kapseln, die den Zustand eines gewünschten Objekts definieren. Dies ist eine sehr leistungsfähige Möglichkeit, die Kopplung zu verringern und die Erweiterbarkeit zu erhöhen, um eine Teilmenge von Objekten auszuwählen, die bestimmten Kriterien entsprechen. Diese Kriterien können mithilfe logischer Operatoren kombiniert werden, um dann das zu bilden, was Eric und Martin Composite Specification nennen. Um das Ziel zu erreichen, müssen Technologien wie Java, Kafka, Cloud Foundry, Istio/Envoy und vor allem das Softwaredesign so harmonisiert werden, dass alle Bits und Teile gut zusammenpassen und eine erweiterbare, sichere, skalierbare und belastbare Lösung bieten, auf die sich unsere Kunden zweifellos verlassen können.

Der zweite auf unserer Liste ist das Iterator-Designmuster. Es ist eine sehr einfache Schnittstelle, die aus einer Methode, IsSatisfiedBy (TCandidate-Kandidat), besteht, die true oder false zurückgibt, je nachdem, ob die angegebene Spezifikation vom Kandidaten erfüllt wird, der an sie übergeben wurde. Jetzt, da wir die Bausteine haben, die zum Erstellen einer Spezifikation erforderlich sind, sind wir bereit, uns die Dinge anzusehen, die wir benötigen, um Spezifikationen zu erstellen, die speziell für unsere Domäne spezifisch sind: Bestandswarnungen. Während wir von der Diskussion der booleschen Spezifikationen zu den sprechen über domänenspezifische Spezifikationen übergehen, verlagert sich unser Fokus von den Zweigknoten (nicht-Blatt) der zusammengesetzten Spezifikation zu den Blattknoten.