Macht der Methoden-Overhead von Objective-C einen Entwurfsansatz mit vielen kleinen Methoden nicht ratsam?

Im Allgemeinen bevorzuge ich die Verwendung kleiner Methoden, wie sie unter anderem von Bob Martin in Clean Code empfohlen werden . Ich habe auch genug über die Interna von Objective-C gelesen, um zumindest eine Vorstellung davon zu haben, wie der Nachrichtenversand von Objective-C funktioniert ( bbums series ist dazu besonders informativ).

Ungeachtet vorzeitiger Optimierungsbedenken würde ich gerne wissen, ob all die Arbeit, die Objective-c mit objc_msgSend leistet, praktisch so aussagekräftig ist, dass der Ansatz "viele kleine Methoden" für Objective-C-Projekte nicht empfehlenswert ist.

Empirische Befunde sind besonders erwünscht (vielleicht stelle ich irgendwann selbst einen Test auf). Die Erfahrung von jedem, der große Objective-C-Projekte geschrieben hat, wäre auch großartig.

Klärung

Der allgemeine Ton der Frage ist beabsichtigt. Ich frage nicht nach der Leistungsoptimierung bestimmter Apps (weshalb ich hier eher frage als bei SO), sondern eher danach, ob die Sprachmerkmale von Objective-C einen bestimmten Designansatz behindern. Ich habe beobachtet, dass ein Großteil des Codes, den ich von Apple und anderen Parteien (auf Github usw.) gesehen habe, in Richtung großer Methoden (und Klassen) tendiert, und ich frage mich, ob dies eine Tendenz ist, die sich aufgrund der Sprache eingeschlichen hat selbst. Natürlich habe ich möglicherweise den falschen Code gelesen, oder es sind eher kulturelle als technische Faktoren, die zu der Tendenz geführt haben, dass der Code existiert.

(Für das, was es wert ist, schreibe ich gerade Objective-C und verwende kleine Methoden.)

Weitere Anfrage

Ich bin mit beiden Antworten einverstanden. Eine weitere Sache, die ich möchte, ist, dass mich jemand auf eine (hoffentlich substanzielle) Open-Source- (oder anderweitig sichtbare) Objective-C-Codebasis hinweist, die nette kurze Methoden (und kleine Klassen) verwendet. Ich habe in Objective-C noch nichts gesehen, was mit der Fitnessquelle verglichen werden könnte .

design coding-style objective-c

— Cris
quelle

Mike Ash hat ein paar nette Posts mit Zahlen für Leopard und iOS . Ich habe diese nicht vollständig verdaut, aber es scheint, dass der Overhead für zwischengespeicherte IMPs vernachlässigbar ist, und selbst bei Sendungen, die eine Suche erfordern, ist er ziemlich gering. Wenn dieser schnelle Eindruck richtig ist, scheint es, dass kleine Methoden in ObjC auf den gleichen Gestaltungsgründen stehen oder fallen wie in jeder anderen Sprache.

— Cris

Wenn Sie diesen Aufwand vermeiden möchten, verwenden Sie C-Funktionen.

— Rightfold

Technisch möglich, aber mit Funktionen geht viel verloren. Ich würde Methoden nur durch Funktionen für gezielte, leistungsabhängige Codeteile ersetzen. Ich frage hier, ob der Overhead problematisch genug ist, um einen bevorzugten Codierungs- / Designstil zu überdenken.

— Cris

Einige gute Antworten finden Sie unter Kosten des Nachrichtenversands in Objective-C für SO.

— Caleb

Warum profilierst du deinen Code nicht einfach in Xcode? Ich verstehe, dass Sie abstrakt und nicht nach spezifischem Code fragen, aber da Sie anscheinend Code mit vielen kleinen Methoden haben, warum sollten Sie ihn nicht ausführen und sich selbst davon überzeugen?

— Caleb

Antworten:

Ich weiß nicht wirklich, ob der Aufwand vernachlässigbar ist oder nicht. Aber ich würde es vorziehen , ein System zu entwerfen leicht verständlich und sein wartbar zuerst , und das normalerweise kleine Mittel konzentrierten sich Methoden und Klassen. Dies hilft sogar bei der nachfolgenden Code-Optimierung (nur weil der Code besser gewartet werden kann). Außerdem ist es wichtig, den Code zu profilieren, um echte Engpässe zu finden, die möglicherweise nicht einmal mit dem Overhead von Methodenaufrufen zusammenhängen. Wenn Sie Vorgänge außerhalb des Prozesses ausführen (z. B. Aufrufe der Datenbank, des Netzwerks oder des Dateisystems), dominieren diese ohnehin die Laufzeit des Programms.

Aber wie immer kann Ihr Kilometerstand variieren ...

— Jordão
quelle

Natürlich stimme ich all dem zu (siehe den Hinweis zu "Onkel Bob" in der Frage). Aber wenn sich eine Sprache nicht generell für einen bestimmten Best-Case-Design-Ansatz eignet, könnten Programmierer andere Entscheidungen treffen. Ich habe nicht viel Objective-C-Code gesehen, der den kleinen Methoden (und Klassen) wirklich folgt, und frage mich, warum. Ich werde der Frage eine Notiz hinzufügen.

— Cris

@Cris: "Ich habe nicht viel Objective-C-Code gesehen, der den kleinen Methoden wirklich folgt." -> Nur neugierig: Aus welchem Code haben Sie eine solche Schlussfolgerung gezogen? Ich glaube daran, aber ich glaube auch, dass es nicht am Bewusstsein für Mikrooptimierung liegt, sondern eher an Programmierern, die sich nicht auf die Grundsätze guten Designs und guter Wartbarkeit konzentrieren. Anders ausgedrückt, ihre Java, C #, Ruby oder was auch immer Code muss die gleichen Praktiken folgen ...

— Jordão

Ja, das ist durchaus möglich. Ich hatte keine bestimmte Codebasis im Sinn; Genau das, was ich mir im Laufe des Jahres angesehen habe. Ich habe mit Objective-C gearbeitet. Der größte Code, den ich mir angesehen habe, war das Open-Source-Material der Omni-Gruppe und IIRC, das viele große Methoden hatte. Der Beispielcode von Apple funktioniert auch häufig. Aber natürlich ist (a) Beispielcode genau das, und (b) mein Beispiel kann in Bezug auf UI-Code gewichtet sein, insbesondere View-Controller, und diese können anders als die tieferen Schichten codiert sein.

— Cris

Die überwiegende Mehrheit des Codes wird in keiner Anwendung leistungskritisch sein. Selbst wenn der Methoden-Overhead im Vergleich zu anderen Sprachen erheblich wäre, bestünde der optimale Ansatz darin, an den meisten Stellen viele kleine Methoden zu verwenden und nur solche zu integrieren, die ein Profil erstellen hat sich als leistungskritisch erwiesen.

Natürlich gibt es viele Leute, die nicht wissen, wie man richtig optimiert, und von denen einige vielleicht etwas über den Overhead von Methoden wissen und sich auf globale vorzeitige Optimierungen einlassen, aber ich glaube nicht, dass diese Gruppe groß genug ist, um einen signifikanten Einfluss zu haben auf das Objective-C-Ökosystem.

Bei großen Methoden und Klassen handelt es sich viel häufiger um die Arbeit einer großen Gruppe von Personen, die nichts über Profiler, Methoden-Overhead oder korrektes Design wissen oder sich darum kümmern und dazu neigen, Big Balls of Mud in einer beliebigen Sprache zu produzieren. Und ja, einige dieser Leute arbeiten an hochkarätigen Codebasen in großen Softwareunternehmen.

— Michael Borgwardt
quelle