Inversion of Control Principle in Swift

99s99m · 30. Juli 2015, 21:33

In C# ist es ratsam das Inversion of Control Principle zu befolgen. Man sollte Interfaces statt konkrete Objekte verwenden. Es ist gut für gute Encapsulation und loose coupling of code.
Außerdem tut man sich beim Unit-Testing und auch Mocking/Dependency Injection leichter.
Ich habe dazu ein Bsp. angehängt.

Mit Swift benötige ich ja nicht wirklich ein Mocking Framework. Das geht ja mit einem Dreizeiler (wie unterhalb sichtbar) sehr gut.

Nun meine Frage: Verwendet man das Inversion of Control Principle auch in Swift (hier Protocols statt Interfaces?) oder gibts andere Techniken? Für Swift habe ich im Web leider nichts gefunden. Für Objective-C hab ich ein paar Artikel gefunden wie bspw. hier:
danielsaidi.wordpress.com/2014…y-approach-to-ioc-in-ios/

Ich bin für jede Auskunft dankbar!

Quellcode

interface ILogWriter
{
void WriteToLog(string message);
}
class DatabaseLogWriter : ILogWriter
{
public void WriteToLog(string message)
{
// make call to webservice and write to database
}
}
class HarddriveLogWriter : ILogWriter
{
public void WriteToLog(string message)
{
File.AppendAllText(@"D:\sample.log", message);
}
}
class LogManager
{
private ILogWriter _logWriter;
public LogManager(ILogWriter logWriter)
{
_logWriter = logWriter;
}
public void WriteToLog(string message)
{
_logWriter.WriteToLog(message);
}
}

Alles anzeigen

Swift Mocking:

Quellcode

class LogWriterMock: ILogWriter {
override func writeToLog(message: String) {
// ...
}
}

macmoonshine · 31. Juli 2015, 07:48

Was ist denn der Unterschied zwischen deinen beiden Listings, außer dass die Swift-Klasse kein Teil des Protokolls ist?

Das Entscheidende in beiden Sprachen ist doch die Abstraktion des Loggings in einer Schnittstelle. Der LogManager macht ja anscheinend nichts wirklich Praktisches und delegiert die einzige Aufgabe auch noch weiter; wie halt Manager so sind.

Den kannst du dir sparen.

Apropos Manager: Das C#-Listing sieht nach ziemlich viel heißer Luft aus. Der LogManager ist ja ein delegierender ILogWriter. Ihm fehlt nur das entsprechende Super-Interface.

Markus Müller · 31. Juli 2015, 09:29

Also IoC hat ja erstmal nix mit der verwendeten Sprache zu tun. Cocoa ist voll davon, Stichwort Delegation, Datasources, NSCoding etc.

Aber das bedeutet nicht zwangsläufig, für alles und jedes ein interface zu verwenden.

Gruß, Markus

Amin Negm-Awad · 31. Juli 2015, 11:17

IOC ist auch nicht die Definition von Protokollen statt Interfaces, sondern verlangt die Definition von Protokollen statt Interfaces, weil das Framework die konkrete Klasse in der Anwendung weder kennen noch vorschreiben kann.

Die von "Professor Blowing your Mind" vorgestellte, jedoch uralte Idee, für alles erst einmal ein Protokoll zu haben, bedeutet erst einmal mehr Arbeit. Das ist schlecht für die Gesundheit. Es ist nützlich, wenn man solche Fragestellungen wie im ersten Absatz hat. Innerhalb der eigenen App mit dem weitreichend bekannten Sourcecode ist es eher unnütz.

Wie bei jedem Muster sollte man bedenken, welches Problem es zu lösen gilt und wieso die Leute auf diese Lösung verfallen.

99s99m · 31. Juli 2015, 13:25

Danke @all für eure Antworten!
Das Bsp. diente nur zur Klarstellung meiner Frage. Ich habe dieses jz noch erweitert. Ich weiß, dass die LogManager Klasse davor keinen Sinn ergeben hat.

Wiegesagt, war das ja nur ein Codeschnipsel.

Meine Frage bezog sich darauf, ob dies in Swift so ähnlich wie in C# gelöst wird bzw. ob es gebräuchlich in Swift ist.

Markus Müller schrieb:

Aber das bedeutet nicht zwangsläufig, für alles und jedes ein interface zu verwenden.

Gute Encapsulation und loose coupling habe ich damit schon erreicht und beim Mocking tu ich mir auch leichter.

Amin Negm-Awad schrieb:

Wie bei jedem Muster sollte man bedenken, welches Problem es zu lösen gilt und wieso die Leute auf diese Lösung verfallen.

Das sehe ich auch so... darum auch meine Frage.

Amin Negm-Awad · 31. Juli 2015, 13:38

Worauf ich – und mutmaßlich auch Markus Müller – hinaus wollten: Du brauchst innerhalb deiner App nur selten Loose-Coupling.

Irgendwann schreiben die Leute nur noch Code, den sie in jedem Projekt weiterverwenden könnten, was jedoch nie geschehen wird, weil sie mit dem Schreiben dieses Codes, den sie in jedem Projekt weiterverwenden könnten, bis an ihr Lebensende beschäftigt sind.

Oder wie es der Volksmund sagen würde: Mit Kanonen auf Spatzen schießen.

macmoonshine · 31. Juli 2015, 14:11

Amin Negm-Awad schrieb:

Irgendwann schreiben die Leute nur noch Code, den sie in jedem Projekt weiterverwenden könnten, was jedoch nie geschehen wird, weil sie mit dem Schreiben dieses Codes, den sie in jedem Projekt weiterverwenden könnten, bis an ihr Lebensende beschäftigt sind.

Andererseits verwenden es die, bei denen es sinnvoll ist, leider viel zu selten. Da kommen dann diese statischen Framework-Monster raus, die man fast komplett neu implementieren muss, nur weil man ein kleines Detail anders haben möchte. Ich bin da mal auf die ersten Swift-Frameworks von Apple gespannt.

Amin Negm-Awad · 31. Juli 2015, 14:17

Als Faustregel habe ich: Was ich in ein Framework stecken würde, abstrahiere ich anständig. Was offenkundig in meinem App-Biotop verbleibt, wird genau so weit abstrahiert, wie ich es gerade brauche. (Tatsächlich neige ich aber auch hierbei dazu, zu überabstrahieren. Ich bessere mich aber, weil Christian genau das Gegenteil macht.)

Ich bin mir ziemlich sicher, dass die Leute, die bei Apple Swift-Frameworks bauen, eher überabstrahieren. Da ist dann Professor "Blowing your Mind" Lead-Engineer. Die Leute werden es toll finden, wie sie C++-Template-Wüsten toll fanden. So richtig techie anstelle von so richtig einfach.

*Schulterzuck* Solange ich dazu nicht gezwungen werde …

Markus Müller · 31. Juli 2015, 18:48

markusschalk schrieb:

Danke @all für eure Antworten!
Das Bsp. diente nur zur Klarstellung meiner Frage. Ich habe dieses jz noch erweitert. Ich weiß, dass die LogManager Klasse davor keinen Sinn ergeben hat.
Wiegesagt, war das ja nur ein Codeschnipsel.

Meine Frage bezog sich darauf, ob dies in Swift so ähnlich wie in C# gelöst wird bzw. ob es gebräuchlich in Swift ist.

Markus Müller schrieb:

Aber das bedeutet nicht zwangsläufig, für alles und jedes ein interface zu verwenden.

Gute Encapsulation und loose coupling habe ich damit schon erreicht und beim Mocking tu ich mir auch leichter.

Amin Negm-Awad schrieb:

Wie bei jedem Muster sollte man bedenken, welches Problem es zu lösen gilt und wieso die Leute auf diese Lösung verfallen.

Das sehe ich auch so... darum auch meine Frage.

Die Frage ist halt immer, an welcher Stelle Deiner App Du encapsulation und loose coupling brauchst. Immer da, wo es über eine boundary geht (in die Viewschicht, zur DB, IO), bietet sich IoC an. Dann kannst Du auch prima testen. Aber u.U. reichen dafür schon simple datastructures, die über ein konkretes interface (sprich ein normales controller/interactor objekt) weiter gereicht wird.

Such mal nach clean architecture und Uncle Bob Martin, der bringt das schön auf den Punkt in diversen Keynotes und Blogposts.

Der Punkt ist allerdings, dass es meistens einfacher ist, die schon vorhandenen Abstraktionen des Frameworks zu verwenden (CoreData, DataSources, KVC), anstatt da das Rad neu zu erfinden.

Zum Testing: mocking frameworks brauche ich so gut wie nie, auch nicht in objective-c.

Beste Grüße, Markus

99s99m · 31. Juli 2015, 19:22

Markus Müller schrieb:

markusschalk schrieb:

Danke @all für eure Antworten!
Das Bsp. diente nur zur Klarstellung meiner Frage. Ich habe dieses jz noch erweitert. Ich weiß, dass die LogManager Klasse davor keinen Sinn ergeben hat.
Wiegesagt, war das ja nur ein Codeschnipsel.

Meine Frage bezog sich darauf, ob dies in Swift so ähnlich wie in C# gelöst wird bzw. ob es gebräuchlich in Swift ist.

Markus Müller schrieb:

Aber das bedeutet nicht zwangsläufig, für alles und jedes ein interface zu verwenden.

Gute Encapsulation und loose coupling habe ich damit schon erreicht und beim Mocking tu ich mir auch leichter.

Amin Negm-Awad schrieb:

Wie bei jedem Muster sollte man bedenken, welches Problem es zu lösen gilt und wieso die Leute auf diese Lösung verfallen.

Das sehe ich auch so... darum auch meine Frage.

Die Frage ist halt immer, an welcher Stelle Deiner App Du encapsulation und loose coupling brauchst. Immer da, wo es über eine boundary geht (in die Viewschicht, zur DB, IO), bietet sich IoC an. Dann kannst Du auch prima testen. Aber u.U. reichen dafür schon simple datastructures, die über ein konkretes interface (sprich ein normales controller/interactor objekt) weiter gereicht wird.
Such mal nach clean architecture und Uncle Bob Martin, der bringt das schön auf den Punkt in diversen Keynotes und Blogposts.

Der Punkt ist allerdings, dass es meistens einfacher ist, die schon vorhandenen Abstraktionen des Frameworks zu verwenden (CoreData, DataSources, KVC), anstatt da das Rad neu zu erfinden.

Zum Testing: mocking frameworks brauche ich so gut wie nie, auch nicht in objective-c.

Beste Grüße, Markus

danke Markus
Das wollte ich wissen