Fehlerbehandlung - try-catch

dit · 31. Mai 2014, 22:24

Hallo

also ich habe hier im Forum aber auch im Internet nach Fehlerbehandlung mit try-catch gesucht und ich kam zum Schluss, dass die iOS-Community eine gewisse Exceptions-Phobie hat

Ich erkläre mal was ihr vor habe und vielleicht könnt ihr mir sagen ob man die Fehlerbehandlung eleganter lösen kann.

Also ich habe Klassen:

RESTClient // Kommunikation mit dem Server
AppModel // Singleton. Verwendet RESTClient

In meinen vielen Views, die AppModel kennen, bekomme ich die Daten beispielsweise so:

Quellcode

- (IBAction)loadDataClicked:(id)sender {
@try {
NSDictionary * data = [[AppModel instance] loadNewData];
//mache was mit den Daten
}
@catch (AppException *exception) {
[exception handle];
}
@catch (NSException *exception) {
//
}
@finally {
//
}
}

Alles anzeigen

Was passiert im RESTClient?

Quellcode

- (NSDictionary *)loadNewData:(NSString *)term forLanguage:(NSString *)lang{
[self _checkConnection];
RequestFactory * requestFactory = [RequestFactory alloc];
NSURLRequest * request;
NSDictionary * response;
//... Lade Daten...
return response;
}
-(NSDictionary*) loadPersonData:(NSInteger)personID {
[self _checkConnection];
RequestFactory * requestFactory = [RequestFactory alloc];
NSURLRequest * request;
NSDictionary * response;
// Lade Daten....
return response;
}
// und viele andere Methode die was vom Server laden. Alle diese Methoden prüfen zuerst ob der Nutzer online ist.
-(void) _checkConnection{
if(![[NetworkUtil instance] isOnline]){
@throw [NoNetworkException exceptionWithName:@"NoNetwork" reason:@"WLAN OFF?" userInfo:nil];
}
}

Alles anzeigen

Ich habe das nun so gemacht wie ich es normalerweise in C# oder Android/Java mache. Ich finde das ist sehr übersichtlich und ist einfach zu verstehen.
Ich gehe immer davon aus, wenn der Benutzer was mit der App macht, dann gibt es auch Internetzugang. Falls nicht, gibt es eine Ausnahme die dann vom RESTClient zu AppModel und dann zu View geht, wo sie schliesslich behandelt wird - der Benutzer bekommt einen AlertDialog zu sehen. Alle meine Exceptions (ParseException, NoNetworkException, LoginTokenExpiredException...) erben vom AppException.
In AppException gibt es die Methode handle die UIAlertView anzeigt. Die konkreten Exception-Klassen liefern nun den gewünschten i18n-Text.

Auf diese Weise habe ich eine if-Abfrage an einer Stelle im ganzen Programm.

Ich bin aber bereit mich an Objective C anzupassen

. Fall dieses Vorgehen unüblich ist, wäre ich für die Aufklärung sehr dankbar.

Grüße

EDIT: .h in Klassennamen entfernt

macmoonshine · 31. Mai 2014, 22:37

dit schrieb:

Was passiert im RESTClient.h?

Da passiert gar nichts; das ist eine Headerdatei, und da kommen nur Deklarationen rein.

Exceptions verwendet man in der Tat sehr sparsam bzw. geizig in Objective C. Sie sind eher mit Errors in Java vergleichbar, da sie laut Doku eher auf Programmierfehler hinweisen sollten. In Cocoa verwendest Du stattdessen Rückgabewerte (z. B. nil) oder Ausgabeparameter (in der Regel vom Typ NSError), sowie natürlich die eleganteren Wege Blocks oder Delegation.

Konzepte aus Java oder C# auf Cocoa zu übertragen, gehen in der Regel in die Hose, weil sie meistens nicht so gut wie die von Cocoa durchdacht sind.

Thallius · 31. Mai 2014, 22:45

Oh kann wo fang ich an

also, so, es fängt mit dem sinnlosen singleton an. Das einzige wozu das gut ist ist, dass es dir die Möglichkeit nimmt aus mehreren Threads Daten lesen. Übelst....

wie würde ich es machen?

ich würde eine Klasse datacontroller erstellen (Name ist egal) welche ich ganz normal instanziere und die dann Daten aus dem Internet holt. Also jeder view erzeugt eine Instanz dieser Klasse. Diese Klasse hat dann eine Methode readData (oder wie auch immer). Diese gibt entweder Daten zurück oder eben NULL wenn es nicht geklappt hat. Wenn du genauere Informationen brauchst warum das Daten abholen schief gelaufen ist,, dann machst du halt noch eine Methode getError() in diese Klasse

daschat übrigens nichts mit Objective-C zu tun. Man kann auch in Java programmieren ohne alles mit exceptions zuzukleistern. Das ist einfach eine Frage wie sauber man programmieren möchte.

gruss

claus

mattik · 31. Mai 2014, 23:18

dit schrieb:

also ich habe hier im Forum aber auch im Internet nach Fehlerbehandlung mit try-catch gesucht und ich kam zum Schluss, dass die iOS-Community eine gewisse Exceptions-Phobie hat

Phobie? Nee, Angst hat hier keiner (obwohl man es, wenn man sich beispielsweise mal den C++-Stack-Unwinding-Woodoo genauer ansieht, mit der Angst zu tun bekommen kann)

Dass man das in Cocoa nicht macht hat einen guten Grund. Auszug aus den Exceptions Programming Topics:

The Cocoa frameworks are generally not exception-safe. The general pattern is that exceptions are reserved for programmer error only, and the program catching such an exception should quit soon afterwards.

Mit anderen Worten: Exceptions sind in Cocoa nicht garantiert stabil. Also, wie schon erwähnt, Rückgabewerte und NSError.

Zu Java-Zeiten hielt ich Exceptions auch für eine feine Sache. Ich komme aber immer mehr zur Überzeugung, dass das ein Irrtum war. Es klingt schon verlockend, einfach aus einem Call Stack ausbrechen zu können. Macht aber die Struktur kaputt.

dit · 1. Juni 2014, 00:35

macmoonshine schrieb:

dit schrieb:

Was passiert im RESTClient.h?

Da passiert gar nichts; das ist eine Headerdatei, und da kommen nur Deklarationen rein.

Das war eine Rhetorische Frage. Ich weiss sehr wohl was das ist, habe ja selber implementiert.

Thallius schrieb:

also,
so, es fängt mit dem sinnlosen singleton an. Das einzige wozu das gut
ist ist, dass es dir die Möglichkeit nimmt aus mehreren Threads Daten
lesen. Übelst....

Na ja ich kann ohne Probleme aus mehreren Threads mit dem Singleton AppModel arbeiten. Außerdem habe ich auf diese Weise die View vom Network und Persistenz getrennt. AppModel ist nichts anderes als eine Facade.

Thallius schrieb:

wie würde ich es machen?

ich würde eine Klasse datacontroller erstellen (Name ist egal) welche ich ganz normal instanziere und die dann Daten aus dem Internet holt. Also jeder view erzeugt eine Instanz dieser Klasse. Diese Klasse hat dann eine Methode readData (oder wie auch immer). Diese gibt entweder Daten zurück oder eben NULL wenn es nicht geklappt hat. Wenn du genauere Informationen brauchst warum das Daten abholen schief gelaufen ist,, dann machst du halt noch eine Methode getError() in diese Klasse

Oh eh...

Also jeder view erzeugt eine Instanz dieser Klasse.

Das ist übel. Überhaupt keine Auslagerung von Objekterzeugung. D.h. also falls deine Klasse DataController sich geändert hat, sagen wir mal Konstruktor (initWith...) muss ich alle Views anpassen? Was ist wenn ich DataController austauschen will? Bei mir wäre das an einer Stelle. Bei dieser Lösung in jeder View.

Dein Vorschlag also gegen Implementierung zu programmieren und nicht gegen die Schnittstelle? :whistling:

Wir haben einen er hat genau so programmiert, ok das war ein Praktikant... wie auch immer es stellt sich nun heraus, dass unsere Organisation die Zusammenarbeit mit einem großen Kartendienstanbieter beendet hat. Nun muss er alle Klassen wo der alte MapClient verwendet wurde anpassen. Das nenn ich überlst

Diese gibt entweder Daten zurück oder eben NULL wenn es nicht geklappt hat. Wenn du genauere Informationen brauchst warum das Daten abholen schief gelaufen ist,, dann machst du halt noch eine Methode getError()

Noch übler. Das heißt also, ich muss ständig mit if(data) überprüfen, ob die Daten vorhanden sind. Also in jeder View noch zusätzlich if(data)? Und das soll sauberprogrammiert sein?

Ich gehe davon aus, dass die Daten auf jeden fall nicht null sind. Immerhin ist es das Normalverhalten. Und falls es dazu kommen soll, dass die Daten nicht vorhanden sind, dann ist es eine Ausnahme. Meine AppModel sorgt dafür, dass entweder gültige Daten geliefert werden oder eine Ausnahme geworfen wird. In der Praxis wird die Ausnahme in unseren Tests (Android und WP), äußerst selten geworfen... ach praktisch nie. Von daher erwarte ich keine null.

Also ich muss mich da noch einlesen wie weit sind die Exceptions "unsicher"

mattik · 1. Juni 2014, 01:28

Du kommst aus der Java-Welt, richtig? Ich lasse jetzt mal die Diskussion um Singletons und Überabstraktion weg, bringt wahrscheinlich nicht viel - muss am Ende jeder selbst entscheiden, wie er das machen will.

Offline zu sein ist mit Sicherheit keine Ausnahmesituation, sondern zu erwartendes Laufzeitverhalten. Das sind typische Sachen, bei denen in Java und Konsorten gerne mal mit Exceptions herumgeworfen wird. Das macht aber das Error Handling nicht einfacher, im Gegenteil. Man kann solche Sachen nicht einfach wegdefinieren.

Was anderes: Ich habe mir den Code oben mal angesehen und finde ihn aus einem anderen Grund bedenklich: Der Code sieht so aus, als ob du Netzwerkaktivitäten blockierend auf dem Hauptthread machst. Gar keine gute Idee (und ich kann mir nicht vorstellen, dass die Android-Version das so macht, denn da würde einem sofort eine NetworkOnMainThreadException um die Ohren fliegen). Also: AppModel sauber als Local Cache implementieren, die Netzwerkaktivitäten asynchron durchführen (gcd, Threads oder wie auch immer) und eine status-Property ins AppModel packen, die den Online-Zustand oder Fehlersituationen abbildet. Dann braucht man auch keine Exceptions mehr.

Amin Negm-Awad · 1. Juni 2014, 06:34

Thalias schlägt nicht vor, gegen die Implementierung zu programmieren. Er schlägt vor, die Instanz einer Klasse genau dort zu erzeugen, wo sie gebraucht wird.

Wenn du ein Problem hast, weil sich "Konstruktoren" (die gibt es in Objective-C nicht, es gibt Alligatoren und Initialisierer) ändern könnten, dann ist das ein Problem deines Sourcecodes und sollte genau dort gelöst werden: Im Sourcecode, also mittels Refactoringtools.

Übrigens braucht man in einem solchen Falle fast nie eine Sourcecodeänderung. Wenn man einen zusätzlichen Parameter möchte, ändert man den Designated-Initializer und setzt im alten DI den Parameter sinnvoll vor. Lies dich bitte in die Initialisierungspattern ein. Das ist auch dienlich, wenn ich deine isolierten +alloc sehe. Gar nicht gut.

Ganz, ganz wichtig: Niemals, nie, nicht programmiert man in Objective-C-Syntax Java-Programme. Das gibt weder ein gutes Objective-C-Programm noch ein gutes Java-Programm. Ich habe das gerade bei einem erlebt, dessen App alle 2 Stunden abraucht. Und zwar mit einem Rauchpilz, der eine Kernspaltung nahelegt.

Amin Negm-Awad · 1. Juni 2014, 06:39

Wie prüfst du eigentlich sicher, ob ein Nutzer online ist. Könnte er nicht nach der Prüfung in einen Tunnel fahren? Oder ist das so ein "Wird schon funktionieren" Pattern aus Java?

Thallius · 1. Juni 2014, 10:18

dit schrieb:

Thallius schrieb:

also,
so, es fängt mit dem sinnlosen singleton an. Das einzige wozu das gut
ist ist, dass es dir die Möglichkeit nimmt aus mehreren Threads Daten
lesen. Übelst....

Na ja ich kann ohne Probleme aus mehreren Threads mit dem Singleton AppModel arbeiten. Außerdem habe ich auf diese Weise die View vom Network und Persistenz getrennt. AppModel ist nichts anderes als eine Facade.

Ein Singleton ist ein Singleton und das existiert nur einmal. Es existiert also auch nur eine Instanz. Wie willst du diese thread safe machen? Sobald mehr als eine Thread gleichzeitig darauf zugreift raucht das ab.

Thallius schrieb:

wie würde ich es machen?

ich würde eine Klasse datacontroller erstellen (Name ist egal) welche ich ganz normal instanziere und die dann Daten aus dem Internet holt. Also jeder view erzeugt eine Instanz dieser Klasse. Diese Klasse hat dann eine Methode readData (oder wie auch immer). Diese gibt entweder Daten zurück oder eben NULL wenn es nicht geklappt hat. Wenn du genauere Informationen brauchst warum das Daten abholen schief gelaufen ist,, dann machst du halt noch eine Methode getError() in diese Klasse

Oh eh...

Also jeder view erzeugt eine Instanz dieser Klasse.

Das ist übel. Überhaupt keine Auslagerung von Objekterzeugung. D.h. also falls deine Klasse DataController sich geändert hat, sagen wir mal Konstruktor (initWith...) muss ich alle Views anpassen? Was ist wenn ich DataController austauschen will? Bei mir wäre das an einer Stelle. Bei dieser Lösung in jeder View.

Dein Vorschlag also gegen Implementierung zu programmieren und nicht gegen die Schnittstelle?

Wir haben einen er hat genau so programmiert, ok das war ein Praktikant... wie auch immer es stellt sich nun heraus, dass unsere Organisation die Zusammenarbeit mit einem großen Kartendienstanbieter beendet hat. Nun muss er alle Klassen wo der alte MapClient verwendet wurde anpassen. Das nenn ich überlst

[X] Du hast keine Anung wovon ich rede.

Was ich Vorschlage hält sich zu 100% an das MVC Model und ist das von Apple bevorzugte Model zur Entwicklung von iOS/OSX Apps.

Diese gibt entweder Daten zurück oder eben NULL wenn es nicht geklappt hat. Wenn du genauere Informationen brauchst warum das Daten abholen schief gelaufen ist,, dann machst du halt noch eine Methode getError()

Noch übler. Das heißt also, ich muss ständig mit if(data) überprüfen, ob die Daten vorhanden sind. Also in jeder View noch zusätzlich if(data)? Und das soll sauberprogrammiert sein?

Ja genau das ist es. Was soll daran unsauber sein? Nur weil du 10 Zeichen mehr Tippen must? Wenn der View selber abfragt ob die Daten NULL sind oder nicht kann man den DatenController ändern wie man will. Der View wird niemals dadurch beeinflusst oder nicht mehr funktionieren. Wenn Du mit Exceptzions arbeitest must du ALLE Views immer ändern wenn du mal eine Exception änderst, hinzufügst oder wegnimmst. Es sein denn es interessiert dich gar nicht was für eine Exception da kommt und warum. Das wäre dann wieder so typisch Java like Exception -> Stacktrace -> Exit(). Pech für den User. Ich versuche Fehler abzufangen und nur dann die Software zu beenden wenn es eine Ausnamhe ist (Wie das Wort Exception schon sagt). Eine nicht vorhandene Internet-Verbidung oder ein gerade nciht aktivier Server oder oder oder ist keine Ausnahme sondern ein Fehler.

Claus

macmoonshine · 1. Juni 2014, 10:29

dit schrieb:

Das war eine Rhetorische Frage.

Ach, tatsächlich?

dit schrieb:

Ich weiss sehr wohl was das ist, habe ja selber implementiert.

Und genau das ist der Fehler: Da gehören keine Implementierungen rein.

dit · 1. Juni 2014, 13:55

macmoonshine schrieb:

dit schrieb:

Das war eine Rhetorische Frage.

Ach, tatsächlich?

dit schrieb:

Ich weiss sehr wohl was das ist, habe ja selber implementiert.

Und genau das ist der Fehler: Da gehören keine Implementierungen rein.

Man man... Natürlich habe ich die Implementierung in .m Datei. Ich hätte statt .h einfach Klasse sagen sollen. Mein Fehler...

@Thallius
Ich glaube da liegt ein Mißverständnis vor. Das ist genau das was ich mache, deswegen auch AppModel... Nur das ich mein Model nicht ständig erzeuge vorallem nicht die konkrete Implementierung. Übelst...

@ all
Also der Code den ich gepostet habe ich selbstverständlich eher Pseudocode ohne Nebenläufigkeit ohne ReachabilityChangedNotification usw. Damit man sich auf das eigentliche Problem konzentriert, nämlich Fehlerbehandlung. Deswegen in der Frage auch fett markiert aber ist halt nicht angekommen...

Eine Klasse in jeder View zu erzeugen ist schlicht und einfach ein miserabler Programmierstil. Ja ich komme aus Java, C++ und C# Welt. Aber objektorientiertes Programmieren mit Hilfe von Muster ist sprachunabhängig und das bringt nichts Objective-C als etwas besonderes darzustellen. Die Entwurfsmuster von Objekterzeugung bis zu Verhaltensmuster sind allgemeingültig. Sie funktionieren in C#, Java, C++ und auch in Objective C.

Zum Thema Exceptions.
Der einziger Grund für mich die Exceptions nicht zu nutzen, ist ihre angebliche "Unsicherheit". Es gibt also ein Werkzeug aber wir sollten es nicht verwenden. Wenn wir es verwenden dann bitte nur zur Entwicklungszeit... Dafür kann ich auch Assertions nehmen. Also entweder liegt hier ein Mißverständnis vor oder die Exceptions und try-catch wurden nicht gescheit in Objective C umgesetzt (liegt wohl am C).

Diese Schwarz-Weiß-Einstellung - Exceptions sind böse - ist erschreckend. Hochgradig unflexibel und kurzsichtig. Ich finds nur gut, dass es Entwickler gibt, die das Thema viel konstruktiver angehen: club15cc.com/code/objective-c/…-we-use-try-catch-finally

Ohne Exception muss ich also NSError * error anlegen und dann noch ständig mit if überprüfen ob die Rückgabe die eigentlich immer gültig ist, doch nil ist. Hätte hätte Fahrradkette... Mir geht es nicht um die vier Zeilen von Code mir geht es mehr um die Lesbarkeit und Zweckmäßigkeit.

Das Thema ist für mich durch. Ich versuche mich natürlich mit NSError anzufreunden, es gibt Paar Stellen im Code wo ich das verwenden könnte.

Grüße

macmoonshine · 1. Juni 2014, 14:03

dit schrieb:

Ohne Exception muss ich also NSError * error anlegen und dann noch ständig mit if überprüfen ob die Rückgabe die eigentlich immer gültig ist, doch nil ist.

Diese Überprüfungen halten sich glücklicherweise auch bei komplexeren Projekten in Grenzen. Dafür entfallen außerdem noch die Null-Pointer-Überprüfungen.

Wie ich oben bereits geschrieben habe, behandeln viele Klassen Fehler über ihr Delegate (oder Blocks).

Thallius · 1. Juni 2014, 14:14

Ich glaube Du verwechselst da Model und Controller bzw trennst das überhaupt nicht.

Naja egal ich bin raus. Machmal wie Du denkst. Ist bestimmt richtig.

Claus

Markus Müller · 1. Juni 2014, 19:00

Also ich muss dem TE hier mal beispringen. Zum Thema Exceptions in Objective-C wurde ja nun alles gesagt, in Obj-c macht man das so nicht aus oben u.a. von Mattik genannten Gründen.
Bzgl. der Verwendung von Entwurfsmustern und guter OO-Parixis schließe ich mich dem TE vollauf an, die sind unabhängig von der Sprache. Ich kann jetzt nur für mich sprechen, aber ich habe eine Menge von den Java-Jungs in letzter Zeit gelernt, sei es über TDD, Patterns, clean-code undsoweiterundsofort.

Jetzt immer bei neuen Leuten die "in objc macht man das aber alles anders, was Du machst ist übelst"-Keule auszupacken ist nicht mein Ding und u.a. wegen des Tons, der immer auch die Musik macht, habe ich manchmal auch keine Lust mehr, mich hier mehr zu beteiligen. @mattik, @macmoonshine - auf Euch beide trifft dieser etwas rantige post absolut NICHT zu, Ihr seid immer hilfsbereite, kompetente und respektvolle Forumsteilnehmer, vor denen ich ein ums andere Mal meinen Hut ziehe!

Gruß, Markus

Fortrackz · 1. Juni 2014, 20:04

Ich komme auch von C# und finde Exceptions eine Klasse Sache, für Debugzwecke oder wenn es mal schnell gehen soll. haha...

Ich finde man benutzt Exceptions genau dann, wenn man nicht drüber nachdenken will welche Fälle eintreffen könnten. Anstatt darüber zu sinnieren und die Fehler schon auszumerzen bevor sie passieren.

Seit ich bei iOS und Objective C angelangt bin, habe ich Blocks und Delegations wie oben schon aufgeführt lieben gelernt. Für das vom TE Problem, wären Blocks ja wohl perfekt.

Zu Singletons:
Ich finde beim ersten Eindruck macht das Sinn es so benutzen wie der TE. Problem ist halt die Threadsicherheit etc.

Soll jeder selber wissen, Singleton ist trotzdem das BÖSE.

Exceptions und ObjC -> geht für mich gar nicht.

macmoonshine · 1. Juni 2014, 20:28

Ich programmiere auch recht viel in Java, und es gibt da zwei Dinge, die mich gewaltig stören:

Ich muss an vielen Stellen Checked Exceptions fangen, obwohl die mich gar nicht interessieren. So ist beispielsweise das Anlegen von URL-Konstanten immer viel unnötiger Code.
Wenn ich eine Methode überschreibe, kann ich die Liste der Checked Exceptions nicht erweitern. Wenn die Methode der Oberklasse beispielsweise IOExceptions wirft, kann ich keine SAXExceptions werfen, obwohl das sehr sinnvoll wäre. Ich muss sie stattdessen verpacken, was meist zu kilometerlangen Stacktraces führt.

Wenn ich so typische Exception-Situationen in Java mit dem entsprechendem Cocoa-Code vergleiche, dann hat Cocoa häufig die kompakteren Konzepte und Exceptions sind da eher überflüssig. In Java habe ich schon x-Mal Methoden geschrieben, die Daten aus einem Stream in ein Bytearray einlesen. In Java sind das so 5 bis 10 Zeilen und in Cocoa eine. In Cocoa bekomme ich als Ergebnis ein NSData-Objekt oder nil; also hat geklappt oder hat nicht geklappt. Das ist in der Regel alles, was mich dabei interessiert.

Das mit nil ist übrigens häufig eine praktische Sache. Bei komplexeren Methoden schlägt vielleicht die Initialisierung eines Objekts fehl und seine Referenz ist dann nil. Anstatt mich dann um diesen speziellen Fehler zu kümmern, kann ich häufig den restlichen Code (mit nil) ausführen, und brauche mich erst am Ende um den Fehler zu kümmern.

lasergans · 1. Juni 2014, 20:46

dit schrieb:

Ich erkläre mal was ihr vor habe und vielleicht könnt ihr mir sagen ob man die Fehlerbehandlung eleganter lösen kann.

Die Idee wäre sich an MVC zu halten: Dein Controller holt die Daten über das Netzwerk, kümmert sich um Sonderfälle (z.B. kein Netz), und bereitet die Daten ordentlich auf als Model. Deine vielen Views bekommen eben das was sie brauchen vom Controller. Somit hast du das Fehlerhandling nur ein Mal.

LG

Amin Negm-Awad · 1. Juni 2014, 20:55

dit schrieb:

Ohne Exception muss ich also NSError * error anlegen und dann noch ständig mit if überprüfen ob die Rückgabe die eigentlich immer gültig ist, doch nil ist. Hätte hätte Fahrradkette... Mir geht es nicht um die vier Zeilen von Code mir geht es mehr um die Lesbarkeit und Zweckmäßigkeit.
Grüße

1. Du musst kein NSError *error anlegen, wenn dich der Fehler nicht interessiert. Es ist in der Regel möglich NULL zu übergeben. Wenn er dich interessiert, ja dann brauchst du eine Referenz auf das Objekt. Quelle surprise.

2. Das if ist klarer und kürzer als ein Exceptionhandler.

Aber letztlich ist das dressejal. Programmiere Objective-C oder lasse es bleiben.

Amin Negm-Awad · 1. Juni 2014, 20:58

Markus Müller schrieb:

Also ich muss dem TE hier mal beispringen. Zum Thema Exceptions in Objective-C wurde ja nun alles gesagt, in Obj-c macht man das so nicht aus oben u.a. von Mattik genannten Gründen.
Bzgl. der Verwendung von Entwurfsmustern und guter OO-Parixis schließe ich mich dem TE vollauf an, die sind unabhängig von der Sprache. Ich kann jetzt nur für mich sprechen, aber ich habe eine Menge von den Java-Jungs in letzter Zeit gelernt, sei es über TDD, Patterns, clean-code undsoweiterundsofort.

Was hat das mit java, C#, C++ oder sonst etwas zu tun? Ich habe große Teile des Objective-Cloud-Dispatchers mit TD entwickelt.

Markus Müller schrieb:

Jetzt immer bei neuen Leuten die "in objc macht man das aber alles anders, was Du machst ist übelst"-Keule auszupacken ist nicht mein Ding und u.a. wegen des Tons, der immer auch die Musik macht, habe ich manchmal auch keine Lust mehr, mich hier mehr zu beteiligen. @mattik, @macmoonshine - auf Euch beide trifft dieser etwas rantige post absolut NICHT zu, Ihr seid immer hilfsbereite, kompetente und respektvolle Forumsteilnehmer, vor denen ich ein ums andere Mal meinen Hut ziehe!

Gruß, Markus

Hängt wohl davon ab, ob jemand, wie jemand der von Objective-C keine Ahnung hat, die Welt erklären möchte …

Markus Müller · 1. Juni 2014, 21:42

Amin Negm-Awad schrieb:

...
Was hat das mit java, C#, C++ oder sonst etwas zu tun? Ich habe große Teile des Objective-Cloud-Dispatchers mit TD entwickelt.

Das hat insofern etwas damit zu tun, als dass es sich manchmal lohnt, über den objc-Tellerrand zu schauen. So ist z.B. die Test-Kultur in der Cocoa-Community...ausbaufähig. Das Refactoring bei einer Java-IDE - AppCode - ist um Längen besser als in Xcode, Test-Toolchain überwiegend von ruby beeinflusst (Specta/Kiwi), CI von Xcode steckt in den Kinderschuhen usw. Ich erhoffe mir diesbzgl. von Apple mehr Ehrgeiz, mal sehen was sie zur WWDC bringen.
Und viele Anti-Patterns durchseuchen eine Menge Cocoa-Code (Stichwort Massive View Controller). Die Abhilfen dafür haben erstmal nichts mit der Sprache zu tun (SOLID), aber lediglich der Hinweis: "in objc macht man das anders" hilft eben nicht jedem weiter, der nicht so in der objc-Materie drinsteht. Das sich eben diese Prinzipien in Cocoa wiederfinden bzw. leicht damit umzusetzen ist dann eine andere Sache. Aber auch da fand ich es durchaus aufschlussreich, mir anzusehen, wie das z.b. bei Java/C#/Ruby gemacht wird.

Markus Müller schrieb:

...
Hängt wohl davon ab, ob jemand, wie jemand der von Objective-C keine Ahnung hat, die Welt erklären möchte …

Hatte jetzt nicht das Gefühl, dass der TE mir die Welt erklären wollte...

Quellcode

Quellcode

Ähnliche Themen