1. Im Regelfall benötige ich genau einen Core-Data-Stack. Templates sind für den Regelfall gedacht und verbauen hier rein gar nichts. Dann ist es absolut richtig, dass im ohnehin als Singleton vorhanden AppDelegate zu machen, anstelle eine weitere Klasse ins Projekt zu legen, die dann für den Regelfall wieder nur instantiert werden muss, einschließlich der Pflege der Lebensdauer, was dann mutmaßlich ohnehin wieder das AppDelegate machen würde. Das ist unnötig verkomplizierend.
2. Das AppDelegate ist eigentlich immer vorhanden. Eine Abhängigkeit hierhin ist also eine Abhängigkeit zu einer generischen Klasse, die unschädlich ist. Ich abstrahiere ja auch nicht eine Abhängigkeit zu NSArray oder NSString weg. Eine eigene Klasse CoreDataStack würde ebenso eine Abhängigkeit erzeugen. Zu wiederum einer – im besten Falle – generischen Klasse. Gewinn: 0.
Dass jemand in Probleme kommt, die mit mehr als minimalen Aufwand zu lösen wären, weil eine Abhängigkeit vom AppDelegate besteht, ist fernliegend.
Übrigens: Wenn man die Projektstruktur ändern muss, weil etwa mehrere Kontexte in einer Applikation existieren – etwa Dokumenten basierte Applikationen – so existiert dafür bereits die Abstraktion NSManagedObjectContext. Ich muss diese Abstraktion nicht erneut abstrahieren.
3. Die Angst vor zu großen Klassen verstehe ich nicht:
3.1. Entweder gehört etwas strukturell zu einer Klasse, dann gehört es strukturell zu dieser Klasse. Oder eben nicht. Das hat etwas mit Struktur zu tun, nicht mit Größe. Sie in Subklassen zu zerlegen, die dann genau den Zweck haben, eine Thematik der Klasse zu behandeln, strukturiert etwas, was nicht strukturiert werden muss. Man landet hier häufig in dem Antipattern, dass Objekte nicht Verantwortungsbereiche darstellen, sondern Module. Module sind keine Klassen oder Objekte.
3.2. Objective-C kennt Kategorien. Wenn einem also etwas zu unübersichtlich wird, kann man dazu greifen. Wir sind ja hier nicht bei Java.
3.3. Wie sieht es eigentlich mit der Angst vor zu großen Projekten aus?
Das ist hier besonders auffällig. Du würdest den im AppDelegate vorhandenen Code 1:1 kopieren. (Daher meine obige Frage.) Parameterliste würden sich nicht verändern, Daten müssten aus dem App(!)-Bundle geladen werden. (Vorsicht: Abhängigkeit!) Das zeigt, dass es nicht um Verantwortung, sondern Modularisierung geht.
Insgesamt: Die einfachste und intuitivste Sache Sache der Welt wird durch theoretisierende Überlegungen verkompliziert. Man kann das natürlich lösen, indem man der Klasse dann noch einen Bundle-Namen mitgibt oder – richtig schön theoretisierend kaputt gemacht – man ein Protokoll definiert, das die API beschreibt und dann noch ein Protokoll für Delegate einbaut, welches die notwendigen Daten wie Bundle-Name holt.
Und wozu gleich noch?
2. Das AppDelegate ist eigentlich immer vorhanden. Eine Abhängigkeit hierhin ist also eine Abhängigkeit zu einer generischen Klasse, die unschädlich ist. Ich abstrahiere ja auch nicht eine Abhängigkeit zu NSArray oder NSString weg. Eine eigene Klasse CoreDataStack würde ebenso eine Abhängigkeit erzeugen. Zu wiederum einer – im besten Falle – generischen Klasse. Gewinn: 0.
Dass jemand in Probleme kommt, die mit mehr als minimalen Aufwand zu lösen wären, weil eine Abhängigkeit vom AppDelegate besteht, ist fernliegend.
Übrigens: Wenn man die Projektstruktur ändern muss, weil etwa mehrere Kontexte in einer Applikation existieren – etwa Dokumenten basierte Applikationen – so existiert dafür bereits die Abstraktion NSManagedObjectContext. Ich muss diese Abstraktion nicht erneut abstrahieren.
3. Die Angst vor zu großen Klassen verstehe ich nicht:
3.1. Entweder gehört etwas strukturell zu einer Klasse, dann gehört es strukturell zu dieser Klasse. Oder eben nicht. Das hat etwas mit Struktur zu tun, nicht mit Größe. Sie in Subklassen zu zerlegen, die dann genau den Zweck haben, eine Thematik der Klasse zu behandeln, strukturiert etwas, was nicht strukturiert werden muss. Man landet hier häufig in dem Antipattern, dass Objekte nicht Verantwortungsbereiche darstellen, sondern Module. Module sind keine Klassen oder Objekte.
3.2. Objective-C kennt Kategorien. Wenn einem also etwas zu unübersichtlich wird, kann man dazu greifen. Wir sind ja hier nicht bei Java.
3.3. Wie sieht es eigentlich mit der Angst vor zu großen Projekten aus?
Das ist hier besonders auffällig. Du würdest den im AppDelegate vorhandenen Code 1:1 kopieren. (Daher meine obige Frage.) Parameterliste würden sich nicht verändern, Daten müssten aus dem App(!)-Bundle geladen werden. (Vorsicht: Abhängigkeit!) Das zeigt, dass es nicht um Verantwortung, sondern Modularisierung geht.
Insgesamt: Die einfachste und intuitivste Sache Sache der Welt wird durch theoretisierende Überlegungen verkompliziert. Man kann das natürlich lösen, indem man der Klasse dann noch einen Bundle-Namen mitgibt oder – richtig schön theoretisierend kaputt gemacht – man ein Protokoll definiert, das die API beschreibt und dann noch ein Protokoll für Delegate einbaut, welches die notwendigen Daten wie Bundle-Name holt.
Und wozu gleich noch?
Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?
