Hallo Spa\u00df-Coder.<\/p>\n
Mit diesem Artikel wollen wir mehr zum Nachdenken anregen und weniger das Thema ausf\u00fchrlich erl\u00e4utern. Das Thema der Abh\u00e4ngigkeiten haben wir mittlerweile in verschiedenen Artikeln immer mal wieder aufgegriffen, sei es beim Test, f\u00fcr das Refaktorisieren oder im Kontext des SRP<\/a>s.<\/p>\n Wir verweisen auf ein Architekturmodell, in dem zumindest funktionale Abh\u00e4ngigkeiten grunds\u00e4tzlich vermieden werden, womit das Testen und verstehen des Codes leichter sein kann.<\/p>\n Ralf Westphal beschreibt das Architekturmodell unter http:\/\/geekswithblogs.net\/theArchitectsNapkin\/archive\/2015\/04\/29\/the-ioda-architecture.aspx<\/a> und auf deutsch unter anderem in seinem Blog unter http:\/\/blog.ralfw.de\/2015\/04\/die-ioda-architektur.html<\/a>.<\/p>\n Eine Beispielimplementierung in Java findet ihr im GitHub unter https:\/\/github.com\/kuniss\/JavaFlow-Examples<\/a>.<\/p>\n Wie sehr kann uns das Modell helfen, den t\u00e4glichen Kampf mit Abh\u00e4ngigkeiten los zu werden? Welche anderen Probleme entstehen dabei? Machen wir das heute nicht eh schon so? Zumindest in der Konsequenten Umsetzung eines z.B. MVC-Musters? Was w\u00fcrde sich \u00e4ndern f\u00fcr die Evolvierbarkeit des Codes?<\/p>\n <\/p>\n