{"id":67,"date":"2015-04-26T14:00:21","date_gmt":"2015-04-26T12:00:21","guid":{"rendered":"http:\/\/ccd.ralfw.domainfactory-kunde.de\/?page_id=67"},"modified":"2024-10-17T10:23:24","modified_gmt":"2024-10-17T08:23:24","slug":"degre-jaune","status":"publish","type":"page","link":"https:\/\/clean-code-developer.de\/fr\/die-grade\/gelber-grad\/","title":{"rendered":"Degr\u00e9 jaune"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-page\" data-elementor-id=\"67\" class=\"elementor elementor-67\" data-elementor-post-type=\"page\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-7d85ed43 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"7d85ed43\" data-element_type=\"section\" data-e-type=\"section\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-1ba2c882\" data-id=\"1ba2c882\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-72443e4 elementor-toc--minimized-on-tablet elementor-widget elementor-widget-table-of-contents\" data-id=\"72443e4\" data-element_type=\"widget\" data-e-type=\"widget\" data-settings=\"{&quot;headings_by_tags&quot;:[&quot;h2&quot;,&quot;h3&quot;],&quot;exclude_headings_by_selector&quot;:[],&quot;marker_view&quot;:&quot;numbers&quot;,&quot;no_headings_message&quot;:&quot;Es wurden keine \\u00dcberschriften auf dieser Seite gefunden.&quot;,&quot;minimize_box&quot;:&quot;yes&quot;,&quot;minimized_on&quot;:&quot;tablet&quot;,&quot;hierarchical_view&quot;:&quot;yes&quot;,&quot;min_height&quot;:{&quot;unit&quot;:&quot;px&quot;,&quot;size&quot;:&quot;&quot;,&quot;sizes&quot;:[]},&quot;min_height_tablet&quot;:{&quot;unit&quot;:&quot;px&quot;,&quot;size&quot;:&quot;&quot;,&quot;sizes&quot;:[]},&quot;min_height_mobile&quot;:{&quot;unit&quot;:&quot;px&quot;,&quot;size&quot;:&quot;&quot;,&quot;sizes&quot;:[]}}\" data-widget_type=\"table-of-contents.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<div class=\"elementor-toc__header\">\n\t\t\t\t\t\t<h4 class=\"elementor-toc__header-title\">\n\t\t\t\tInhaltsverzeichnis\t\t\t<\/h4>\n\t\t\t\t\t\t\t\t\t\t<div class=\"elementor-toc__toggle-button elementor-toc__toggle-button--expand\" role=\"button\" tabindex=\"0\" aria-controls=\"elementor-toc__72443e4\" aria-expanded=\"true\" aria-label=\"Inhaltsverzeichnis \u00f6ffnen\"><i aria-hidden=\"true\" class=\"fas fa-chevron-down\"><\/i><\/div>\n\t\t\t\t<div class=\"elementor-toc__toggle-button elementor-toc__toggle-button--collapse\" role=\"button\" tabindex=\"0\" aria-controls=\"elementor-toc__72443e4\" aria-expanded=\"true\" aria-label=\"Inhaltsverzeichnis schlie\u00dfen\"><i aria-hidden=\"true\" class=\"fas fa-chevron-up\"><\/i><\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<div id=\"elementor-toc__72443e4\" class=\"elementor-toc__body\">\n\t\t\t<div class=\"elementor-toc__spinner-container\">\n\t\t\t\t<i class=\"elementor-toc__spinner eicon-animation-spin eicon-loading\" aria-hidden=\"true\"><\/i>\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<div class=\"elementor-element elementor-element-625d1425 elementor-widget elementor-widget-text-editor\" data-id=\"625d1425\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<h2>Prinzipien<\/h2>\n<h3>Interface Segregation Principle (ISP)<\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nLeistungsbeschreibungen, die unabh\u00e4ngig von einer konkreten Erf\u00fcllung sind, machen unabh\u00e4ngig.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nDas Interface Segregation Principle (<a title=\"ISP\" href=\"https:\/\/drive.google.com\/file\/d\/0BwhCYaYDn8EgOTViYjJhYzMtMzYxMC00MzFjLWJjMzYtOGJiMDc5N2JkYmJi\/view\" target=\"_blank\" rel=\"noopener noreferrer\">ISP<\/a>) ist ein weiteres <a title=\"SOLID\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/solid\/\">SOLID<\/a> Prinzip. <i>Segregation<\/i> bedeutet <i>Abtrennung<\/i>. Das Prinzip besagt, dass ein Client nicht von Details eines Service abh\u00e4ngig sein soll, die er gar nicht ben\u00f6tigt. Je weniger in dessen Interface enthalten ist, desto geringer ist die Kopplung zwischen den beiden Komponenten.\n\nStellen wir uns vor, wir m\u00fcssten einen Stecker planen, mit dem ein Monitor an einen Computer angeschlossen werden soll. Wir entscheiden uns, einfach alle Signale die in einem Computer so anfallen, per Stecker zur Verf\u00fcgung zu stellen. Der hat dann zwar einige Hundert Pins, aber daf\u00fcr ist er maximal flexibel. Dummerweise ist damit die Kopplung ebenfalls maximal.\n\nBeim Beispiel des Steckers ist es offensichtlich, dass eine Monitorverbindung nur jene Signale enthalten soll, die zur Darstellung eines Bildes auf dem Monitor erforderlich sind. Genauso verh\u00e4lt es sich mit Software Interfaces. Auch sie sollten so klein wie m\u00f6glich sein, um unn\u00f6tige Kopplung zu vermeiden. Und genau wie beim Monitorstecker sollte das Interface eine hohe Koh\u00e4sion haben: Es sollte nur Dinge enthalten, die wirklich eng zusammen geh\u00f6ren.\n\nUm das Interface Segregation Principle anzuwenden, stehen die beiden Refaktorisierungen <a title=\"Extract Interface\" href=\"http:\/\/refactoring.com\/catalog\/extractInterface.html\" target=\"_blank\" rel=\"noopener noreferrer\">Extract Interface<\/a> und <a title=\"Extract Superclass\" href=\"http:\/\/refactoring.com\/catalog\/extractSuperclass.html\" target=\"_blank\" rel=\"noopener noreferrer\">Extract Superclass<\/a> zur Verf\u00fcgung.\n<h4>Quellen<\/h4>\n<table>\n<thead>\n<tr>\n<th>Quelle<\/th>\n<th>Autor<\/th>\n<th>Kurzbeschreibung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>ObjectMentor<\/td>\n<td>Robert C. Martin<\/td>\n<td>Artikel zum Interface Segregation Principle von 1996, ver\u00f6ffentlicht im Engineering Notebook f\u00fcr <i>The C++ Report<\/i><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><span id=\"Dependency_Inversion_Principle\">Dependency Inversion Principle (DIP)<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nPunktgenaues Testen setzt Isolation von Klassen voraus. Isolation entsteht, wenn Klassen keine Abh\u00e4ngigkeiten von Implementationen mehr enthalten \u2013 weder zur Laufzeit, noch zur \u00dcbersetzungszeit. Konkrete Abh\u00e4ngigkeiten sollten deshalb so sp\u00e4t wie m\u00f6glich entschieden werden. Am besten zur Laufzeit.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nAuch das Dependency Inversion Principle (<a title=\"DIP\" href=\"https:\/\/drive.google.com\/file\/d\/0BwhCYaYDn8EgMjdlMWIzNGUtZTQ0NC00ZjQ5LTkwYzQtZjRhMDRlNTQ3ZGMz\/view\" target=\"_blank\" rel=\"noopener noreferrer\">DIP<\/a>) ist ein <a title=\"SOLID\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/solid\/\">SOLID<\/a> Prinzip. Es besagt folgendes:\n<ul>\n \t<li>High-Level Klassen sollen nicht von Low-Level Klassen abh\u00e4ngig sein, sondern beide von Interfaces.<\/li>\n \t<li>Interfaces sollen nicht von Details abh\u00e4ngig sein, sondern Details von Interfaces.<\/li>\n<\/ul>\nVerwendet eine High-Level Klasse eine Low-Level Klasse unmittelbar, so ergibt sich eine starke Kopplung zwischen beiden. Sp\u00e4testens beim Versuch, die High-Level Klasse isoliert zu testen, wird man auf Schwierigkeiten sto\u00dfen. Aus diesem Grund sollte die High-Level Klasse von einem Interface abh\u00e4ngig sein, das wiederum von der Low-Level Klasse implementiert wird. So kann die Low-Level Klasse im Unit Test durch ein <i>Mockup<\/i> ersetzt werden.\n\nUm zur Laufzeit die invertierte, abstrakte Abh\u00e4ngigkeit mit einem konkreten Objekt aufzul\u00f6sen, bieten sich im Prinzip drei M\u00f6glichkeiten:\n<ul>\n \t<li>mittels Konstruktorparameter &#8222;per Hand&#8220;<\/li>\n \t<li>Einsatz eines Inversion of Control Containers (IoC Container) wie etwa Castle Windsor<\/li>\n \t<li>Dependency Lookup<\/li>\n<\/ul>\nIm <a title=\"Gelber Grad\" href=\"http:\/\/clean-code-developer.de\/die-grade\/gelber-grad\/\">gelben Grad<\/a> injizieren wir die Abh\u00e4ngigkeiten zun\u00e4chst nur \u00fcber die Parameter der Konstruktoren. Dies ist anfangs die einfachste L\u00f6sung und funktioniert mit einer handvoll Klassen ganz gut. Sp\u00e4ter im <a title=\"Gr\u00fcner Grad\" href=\"http:\/\/clean-code-developer.de\/die-grade\/gruener-grad\/\">gr\u00fcnen Grad<\/a> nutzen wir einen IoC Container und Dependency Lookup.\n<h4>Quellen<\/h4>\n<table>\n<thead>\n<tr>\n<th>Quelle<\/th>\n<th>Autor<\/th>\n<th>Kurzbeschreibung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>objectmentor<\/td>\n<td>Robert C. Martin<\/td>\n<td>Artikel zum Dependency Inversion Principle von 1996, ver\u00f6ffentlicht im Engineering Notebook f\u00fcr <i>The C++ Report<\/i><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><span id=\"Liskov_Substitution_Principle\">Liskov Substitution Principle (LSP)<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nWer mit Erben zu tun hat, m\u00f6chte keine \u00dcberraschungen erleben, wenn er mit Erblassern vertraut ist.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nAuch das Liskov Substitution Principle (<a title=\"LSP\" href=\"https:\/\/drive.google.com\/file\/d\/0BwhCYaYDn8EgNzAzZjA5ZmItNjU3NS00MzQ5LTkwYjMtMDJhNDU5ZTM0MTlh\/view\" target=\"_blank\" rel=\"noopener noreferrer\">LSP<\/a>) ist ein <a title=\"SOLID\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/solid\/\">SOLID<\/a> Prinzip. Es besagt, dass Subtypen sich so verhalten m\u00fcssen wie ihr Basistyp. Dies klingt zun\u00e4chst banal. Am Beispiel von Exceptions wird deutlich, welche Probleme entstehen, wenn das Prinzip verletzt wird: L\u00f6st der Basistyp bei der Ausf\u00fchrung einer Methode keine Exception aus, m\u00fcssen alle Subtypen sich an diese Regel halten. L\u00f6st die Methode eines Subtyps dennoch eine Exception aus, w\u00fcrde dies bei Verwendern, die ein Objekt vom Basistyp erwarten, Probleme verursachen, weil sie nicht darauf vorbereitet sind. Wenn der Basistyp an der Stelle keine Exception ausl\u00f6st, ist der Verwender nicht darauf eingestellt, Exceptions behandeln zu m\u00fcssen.\n\nAllgemeiner kann man das Prinzip auch so ausdr\u00fccken, dass ein Subtyp die Funktionalit\u00e4t eines Basistyps lediglich erweitern, aber nicht einschr\u00e4nken darf. Wenn eine Methode im Basistyp auf einem bestimmten Wertebereich definiert ist, darf der Subtyp diesen Wertebereich \u00fcbernehmen oder auch erweitern, er darf ihn jedoch keinesfall einschr\u00e4nken.\n\nAus dem Liskov Substitution Principle ergibt sich ferner die Empfehlung, \u00fcber Vererbung sehr genau nachzudenken. In den allermeisten F\u00e4llen ist die Komposition der Vererbung vorzuziehen (<i>Favor Composition over Inheritance<\/i>). Bei der Vererbung sollte man in jedem Fall \u00fcber das Verhalten nachdenken, nicht nur \u00fcber die Struktur. Statt Vererbung als<i>is-a<\/i> Relation zu betrachten und dabei nur die (Daten-)Struktur zu bedenken, sollte man besser von einer <i>behaves-as<\/i> Relation ausgehen und das Verhalten der Klasse ber\u00fccksichtigen.\n<h4>Quellen<\/h4>\n<table>\n<thead>\n<tr>\n<th>Quelle<\/th>\n<th>Autor<\/th>\n<th>Kurzbeschreibung<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>objectmentor<\/td>\n<td>Robert C. Martin<\/td>\n<td>Artikel zum Liskov Substitution Principle von 1996, ver\u00f6ffentlicht im Engineering Notebook f\u00fcr <i>The C++ Report<\/i><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Principle of Least Astonishment<\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nWenn sich eine Komponente \u00fcberraschenderweise anders verh\u00e4lt als erwartet, wird ihre Anwendung unn\u00f6tig kompliziert und fehleranf\u00e4llig.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nSoftwareentwicklung ist in hohem Ma\u00dfe ein kreativer Prozess. In diesem Prozess ist es wichtig, in den Fluss einzutauchen (engl. Flow). Wenn man diesen Zustand erreicht hat, sprudelt der Code nur so heraus. Jegliche St\u00f6rung des Flow f\u00fchrt zu Unterbrechungen und letztlich dazu, dass in der zur Verf\u00fcgung stehenden Zeit nur wenig Code produziert wird bzw. die Qualit\u00e4t des Code nicht optimal ist. Denn nach jeder Unterbrechung muss der Entwickler erst wieder Fahrt aufnehmen und erneut in den Fluss zu kommen. \u00dcberraschungen stellen St\u00f6rungen dar. Sie f\u00fchren zu Unterbrechungen und Fehlern. Dazu ein Beispiel: Ist die Tastenbelegung in der Entwicklungsumgebung so gew\u00e4hlt, dass eine \u00fcbliche Tastenkombination wie z.B. Ctrl-C eine v\u00f6llig andere Bedeutung hat, behindert dies den Entwickler. Ein Entwickler wird sich jedesmal \u00e4rgern, wenn er die &#8222;falsche&#8220; Tastenkombination verwendet. Dies behindert kreatives Arbeiten.\n\nSoftware sollte \u00fcberraschungsarm implementiert sein. Wenn eine Abfragemethode namens <i>GetValue()<\/i> nicht nur einen Wert liefert, sondern gleichzeitig den Zustand des Systems \u00e4ndert, wird der Entwickler diese Methode im besten Fall meiden, da er mit b\u00f6sen \u00dcberraschungen rechnet. Im ung\u00fcnstigen Fall f\u00e4llt ihm dieses merkw\u00fcrdige Verhalten nicht rechtzeitig auf. (Abfragemethoden die den Zustand \u00e4ndern, versto\u00dfen gegen das <i>Command Query Separation<\/i> Prinzip). Die testgetriebene Entwicklung f\u00f6rdert \u00fcberraschungsarme Schnittstellen, da die Schnittstelle aus der Sichtweise ihrer Verwendung entworfen und implementiert wird.\n<h3>Information Hiding Principle<\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nDurch das Verbergen von Details in einer Schnittstelle werden die Abh\u00e4ngigkeiten reduziert.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nBeim Design einer Schnittstelle sollte man sich fragen, welche Details au\u00dfen unbedingt sichtbar sein m\u00fcssen. Mit Schnittstelle sind hier nicht nur Interfaces im objektorientierten Sinne gemeint, sondern auch implizite Schnittstellen. Jede Klasse hat zwangsl\u00e4ufig eine implizite Schnittstelle \u2013 sie enth\u00e4lt alle nach au\u00dfen sichtbaren Details. Je mehr Details von au\u00dfen sichtbar sind, desto h\u00f6her ist die Kopplung zwischen der Klasse und ihren Verwendern. Benutzen die Verwender einer Klasse erstmal ein Detail, wird es schwerer, dieses Detail zu ver\u00e4ndern. Dies steht der Wandelbarkeit der Software entgegen.\n<h2>Praktiken<\/h2>\n<h3><span id=\"Automatisierte_Unit_Tests\">Automated Unit Tests<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nNur automatisierte Tests werden auch wirklich konsequent ausgef\u00fchrt. Je punktgenauer sie Code testen, desto besser.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nIm <a title=\"Oranger Grad\" href=\"http:\/\/clean-code-developer.de\/die-grade\/orangener-grad\/\">orangen Grad<\/a> haben wir Integrationstests eingef\u00fchrt, nun geht es um Unit Tests. Im Gegensatz zu Integrationstests wird bei Unit Tests eine einzelne Funktionseinheit (vor allem Klassen, aber auch Methoden oder Komponenten) isoliert getestet. Dazu ist es erforderlich, diese Funktionseinheit von ihren Abh\u00e4ngigkeiten befreien zu k\u00f6nnen. Sollen Unit Tests im Nachhinein f\u00fcr bestehenden Code erg\u00e4nzt werden, sind h\u00e4ufig Refaktorisierungen erforderlich. Wir haben durch die Integrationstests die Sicherheit, dass wir dabei keine Fehler einbauen.\n\nAutomatisierte Tests bieten zweifachen Nutzen:\n<ul>\n \t<li>Sie sparen Zeit<\/li>\n \t<li>Sie nehmen Angst<\/li>\n<\/ul>\nJe st\u00e4rker eine Codebasis in Ver\u00e4nderung begriffen ist, desto eher ist die Zeitersparnis zu sp\u00fcren. Denn wo Code sich ver\u00e4ndert, muss immer wieder Neues und auch Altes (Regressionstests) getestet werden. Da spart Automatisation einfach Zeit. Und je komplexer der Code, desto gr\u00f6\u00dfer ist die Angstreduktion. Denn wenn komplexer Code ver\u00e4ndert werden soll \u2013 um Funktionalit\u00e4t hinzuzuf\u00fcgen, ihn zu optimieren oder schlicht zu korrigieren \u2013, da besteht hohe Gefahr, ungewollt Fehler einzuf\u00fchren. Kleinschrittige automatisierte Tests decken diese jedoch auf, sodass kein Grund zur Angst besteht, zu &#8222;verschlimmbessern&#8220;.\n\nSiehe auch unter <a title=\"Tools\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/werkzeuge\/\">Tools<\/a>.\n<h3><span id=\"Mockups_Testattrappen\">Mockups<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nOhne Attrappen keine einfach kontrollierbaren Tests.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nIn der Regel verwenden Komponenten andere Komponenten. Will man eine Komponente isoliert testen, m\u00fcssen diese Abh\u00e4ngigkeiten abgetrennt werden. Dabei interessiert uns nun ausschlie\u00dflich die Funktionalit\u00e4t der zu testenden Komponente (<i>System Under Test (SUT)<\/i>). Und es interessiert uns, wie die Komponente mit den anderen interagiert.\n\nBeim Isolieren verwenden wir sogenannte Mockups. Diese werden anstelle der echten Komponenten verwendet. So interagiert das System Under Test w\u00e4hrend der Tests mit gut kontrollierbaren Attrappen statt mit realen Komponenten.\n\nDie Literatur kennt noch andere Bezeichnungen f\u00fcr Attrappen wie <i>Stub<\/i>, <i>Dummy<\/i> oder <i>Fake<\/i>, die teilweise synonym zu Mockup benutzt werden, aber durchaus f\u00fcr <a title=\"unterschiedliche Funktionsweisen\" href=\"http:\/\/martinfowler.com\/articles\/mocksArentStubs.html\" target=\"_blank\" rel=\"noopener noreferrer\">unterschiedliche Funktionsweisen<\/a> stehen. Bevor man ein Mock Framework wie z.B. <a title=\"Rhino Mocks\" href=\"https:\/\/hibernatingrhinos.com\/oss\/rhino-mocks\" target=\"_blank\" rel=\"noopener noreferrer\">Rhino Mocks<\/a> verwendet, sollte man ein Mockup zun\u00e4chst &#8222;per Hand&#8220; implementieren. Dies hilft, den Mechanismus zu verstehen.\n\nSiehe auch unter <a title=\"Tools\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/werkzeuge\/\">Tools<\/a>.\n<h3><span id=\"Code_Coverage_Analyse\">Code Coverage Analysis<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nTraue nur Tests, von denen du wei\u00dft, dass sie auch wirklich das Testareal abdecken.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nUnit Tests sollten nach M\u00f6glichkeit alle Pfade durch unseren Code abdecken. Nur so gewinnen wir das Vertrauen, dass der Code korrekt arbeitet. Um in Erfahrung zu bringen, welche Codebereiche bislang nicht durch Tests abgedeckt sind, bedienen wir uns der <i>Code Coverage Analyse<\/i>. Diese dient dazu, Bereiche im Code aufzudecken, die noch nicht w\u00e4hrend der automatisierten Tests ausgef\u00fchrt werden.\n\nUnit Tests sollten eigentlich 100% des zu testenden Codes abdecken. Zwar bedeutet das nicht automatisch, dass gen\u00fcgend Tests existieren, doch weniger als 100% Code Coverage zeigen an, dass es noch Taschen von Code gibt, \u00fcber die \u00fcberhaupt noch keine Korrektheitsaussage gemacht werden kann. 100% Codeabdeckung sind deshalb immer anzustreben.\n\nIn der Praxis zeigt es sich jedoch, dass 100% Codeabdeckung nicht immer mit unmittelbar vertretbarem Aufwand erreicht werden k\u00f6nnen. Wie auch sonst im Leben kann die M\u00fche f\u00fcr die letzten 2,3,4 Prozent \u00fcberproportional wachsen. Deshalb kann es nach genauer Analyse der Abdeckungslage akzeptabel sein, mit weniger als 100% zufrieden zu sein.\n\nUnterhalb von 90% ist die Abdeckung dann allerdings so l\u00f6chrig, dass sie als unprofessionell anzusehen ist. Wer also mit automatischen Tests beginnt, sollte immer auch gleichzeitig die Codeabdeckung messen. Sonst l\u00e4sst sich keine Aussage \u00fcber die Qualit\u00e4t der Tests machen.\n\nF\u00fcr die Messung der Code\u00fcberdeckung gibt es zwei einfache Kennzahlen, die als C0- und C1-Kennzahlen bezeichnet werden. Die C0-Kennzahl misst die Anweisungs\u00fcberdeckung, wogegen die C1-Kennzahl die Entscheidungs\u00fcberdeckung bzw. die Zweig\u00fcberdeckung misst.\n<pre>C0 = (Anzahl der getesteten Anweisungen \/ Anzahl der gesamten Anweisungen) * 100%\n<\/pre>\n<pre>C1 = (Anzahl der getesteten Entscheidungen bzw. Zweige \/ Anzahl der gesamten Entscheidungen bzw. Zweige) * 100%\n<\/pre>\nC1 ist dabei die st\u00e4rkere Kennzahl, da 100% Entscheidungs\u00fcberdeckung bzw. Zweig\u00fcberdeckung 100% Anweisungs\u00fcberdeckung impliziert. Der Umkehrschluss gilt nicht.\n\nDer Anweisungs\u00fcberdeckungstest sowie der Zweig\u00fcberdeckungstest arbeiten auf Basis eines Kontrollflussgraphen, siehe <a title=\"Kontrollflussgraph\" href=\"http:\/\/de.wikipedia.org\/wiki\/Kontrollflussgraph\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/de.wikipedia.org\/wiki\/Kontrollflussgraph<\/a>, w\u00e4hrend der Entscheidungs\u00fcberdeckungstest direkt auf dem Quellcode basiert. Die Testverfahren Anweisungs\u00fcberdeckungstest und Zweig\u00fcberdeckungstest sind sehr gut unter\u00a0<a title=\"Kontrollflussorientierte Testverfahren\" href=\"http:\/\/de.wikipedia.org\/wiki\/Kontrollflussorientierte_Testverfahren\" target=\"_blank\" rel=\"noopener noreferrer\">http:\/\/de.wikipedia.org\/wiki\/Kontrollflussorientierte_Testverfahren<\/a> beschrieben.\n\nSiehe auch unter <a title=\"Tools\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/werkzeuge\/\">Tools<\/a>.\n<h3><span id=\"Teilnahme_an_Fachveranstaltungen\">Partizipation in Professional Events<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nAm besten lernen wir von anderen und in Gemeinschaft.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nUm nicht nur &#8222;im eigenen Saft zu schmoren&#8220;, ist es wichtig, regelm\u00e4\u00dfig mit anderen Softwareentwicklern zu diskutieren und Erfahrungen auszutauschen. Um dabei auch \u00fcber den Tellerrand zu blicken, sollte der Austausch mit Entwicklern au\u00dferhalb des eigenen Teams, der t\u00e4glichen Routine, erfolgen. Gut geeignet sind User Groups, die sich in allen Regionen Deutschlands finden lassen.\n\nBei den regionalen User Groups steht der Erfahrungsaustausch im Vordergrund. Der ist wichtig. Je l\u00e4nger der aber innerhalb derselben Gruppe stattfindet, je besser man die Gespr\u00e4chspartner kennt, desto mehr gleichen sich die Meinungen auch in einer User Group wieder an. Deshalb ist es wichtig, immer wieder auch \u00fcber diesen Tellerrand hinaus zu schauen. Neues Gedankenfutter und Diskussionen mit ganz anderen Entwicklern bieten daf\u00fcr \u00fcberregionale Entwicklerkonferenzen.\n\nF\u00fcr Gedankenaustausch und Inspiration sollte ein CCD also drei Ebenen im Blick behalten: das eigene Entwicklerteam, die regionale User Group und die \u00fcberregionale Konferenz. Jede Ebene hat dabei ihren eigenen Rhythmus: t\u00e4glich, monatlich, j\u00e4hrlich.\n\nLinks:\n<ul>\n \t<li><a title=\".Net User Groups in Deutschlands\" href=\"http:\/\/ineta-deutschland.de\/user-groups\/\" target=\"_blank\" rel=\"noopener noreferrer\">.Net User Groups in Deutschlands<\/a><\/li>\n \t<li><a title=\"Python User Groups in Deutschland\" href=\"https:\/\/wiki.python.org\/moin\/LocalUserGroups#User_Groups\" target=\"_blank\" rel=\"noopener noreferrer\">Python User Groups in Deutschland<\/a><\/li>\n \t<li><a title=\"Einige deutsche Java User Groups\" href=\"http:\/\/web.archive.org\/web\/20120305144023\/http:\/\/www.ijug.eu:80\/index.php?option=com_content&amp;view=article&amp;id=6&amp;Itemid=26\" target=\"_blank\" rel=\"noopener noreferrer\">Einige deutsche Java User Groups<\/a><\/li>\n \t<li><a title=\"IT-Termine in Karlsruhe\" href=\"http:\/\/ka.stadtblog.de\/it-termine\" target=\"_blank\" rel=\"noopener noreferrer\">IT-Termine in Karlsruhe<\/a><\/li>\n<\/ul>\n<h3><span id=\"Komplexe_Refaktorisierungen\">Complex Refactorings<\/span><\/h3>\n<div class=\"box\"><strong>Warum?<\/strong>\nEs ist nicht m\u00f6glich, Code direkt in der ultimativen Form zu schreiben.<\/div>\n<div class=\"core-points\">\n<table>\n<tbody>\n<tr>\n<th>Wandelbarkeit<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Korrektheit<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Produktionseffizienz<\/th>\n<td><i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Kontinuierliche Verbesserung<\/th>\n<td><i class=\"fa fa-star\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i>\u00a0<i class=\"fa fa-star-o\"><\/i><\/td>\n<\/tr>\n<tr>\n<th>Single Developer<\/th>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nBereits im <a title=\"Roter Grad\" href=\"http:\/\/clean-code-developer.de\/die-grade\/roter-grad\/\">roten Grad<\/a> sind einfache Refaktorisierungen eingef\u00fchrt worden. Doch <i>Umbenennen<\/i> und <i>Methode extrahieren<\/i> reichen nicht aus, um den Code zu verbessern \u2013 oft sind gr\u00f6\u00dfere Eingriffe erforderlich. Die Einteilung in einfache und komplexe Refaktorisierungen ist sinnvoll, weil komplexe Refaktorisierungen nur mit vorhandenen automatisierten Tests effizient und risikolos zu bewerkstelligen sind. Ohne Tests w\u00e4re nach dem Refaktorisieren nicht bekannt, ob der Code immer noch korrekt ist.\n\nSiehe auch unter <a title=\"refactoring-legacy-code.net\" href=\"http:\/\/refactoring-legacy-code.net\/category\/komplexe-refactorings\/\">refactoring-legacy-code.net<\/a> sowie unter <a title=\"Tools\" href=\"http:\/\/clean-code-developer.de\/weitere-infos\/werkzeuge\/\">Tools<\/a>.\n\nWeiter geht es beim <a title=\"Gr\u00fcner Grad\" href=\"http:\/\/clean-code-developer.de\/die-grade\/gruener-grad\/\">gr\u00fcnen Grad<\/a>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>Inhaltsverzeichnis Prinzipien Interface Segregation Principle (ISP) Warum? Leistungsbeschreibungen, die unabh\u00e4ngig von einer konkreten Erf\u00fcllung sind, machen unabh\u00e4ngig. Wandelbarkeit \u00a0\u00a0 Korrektheit \u00a0\u00a0 Produktionseffizienz \u00a0\u00a0 Kontinuierliche Verbesserung \u00a0\u00a0 Single Developer Das Interface Segregation Principle (ISP) ist ein weiteres SOLID Prinzip. Segregation bedeutet Abtrennung. Das Prinzip besagt, dass ein Client nicht von Details eines Service abh\u00e4ngig sein soll, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":17,"menu_order":4,"comment_status":"closed","ping_status":"closed","template":"","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"class_list":["post-67","page","type-page","status-publish","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/pages\/67","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/comments?post=67"}],"version-history":[{"count":5,"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/pages\/67\/revisions"}],"predecessor-version":[{"id":903,"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/pages\/67\/revisions\/903"}],"up":[{"embeddable":true,"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/pages\/17"}],"wp:attachment":[{"href":"https:\/\/clean-code-developer.de\/fr\/wp-json\/wp\/v2\/media?parent=67"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}