Il sovraccarico del metodo di obiett-c rende sconsigliabile un approccio alla progettazione di "molti piccoli metodi"?

In genere preferisco utilizzare metodi di piccole dimensioni, come raccomandato, tra gli altri, da Bob Martin in Clean Code . Ho anche letto abbastanza degli interni di Objective-C per avere almeno qualche idea su come funziona la sua spedizione di messaggi (la serie di bbum è particolarmente istruttiva su questo).

Nonostante le preoccupazioni sull'ottimizzazione precoce, vorrei sapere se tutto quel lavoro che Objective-c fa con objc_msgInvia è, in termini pratici, abbastanza significativo da rendere sconsigliabile l'approccio dei "molti piccoli metodi" per i progetti Objective-C.

I risultati empirici sono particolarmente ben accetti (forse un giorno organizzerò un test da solo). Anche l'esperienza di chiunque abbia scritto grandi progetti con obiettivi-c sarebbe fantastica.

Una precisazione

Il tono generale della domanda è intenzionale. Non sto chiedendo informazioni sull'ottimizzazione delle prestazioni di app specifiche (motivo per cui chiedo qui piuttosto che su SO), ma piuttosto se le caratteristiche del linguaggio di Objective-C scoraggiano un certo approccio progettuale. Ho osservato che gran parte del codice che ho visto da Apple e altre parti (su github ecc.) Tende a metodi (e classi) di grandi dimensioni, e mi chiedo se questo è un pregiudizio che si è insinuato a causa della lingua si. Naturalmente potrei aver letto il codice sbagliato, oppure potrebbero essere fattori culturali piuttosto che tecnici che hanno portato alla tendenza, se esiste.

(Per quello che vale, sto scrivendo Objective-C e sto usando piccoli metodi)

Ulteriore richiesta

Sono d'accordo con entrambe le risposte che sono state fornite. Un'altra cosa che mi piacerebbe è che qualcuno mi indicasse una base di codice Objective-C (o sostanzialmente visibile) open source (o altrimenti visibile) che utilizza simpatici metodi brevi (e piccole classi). Non ho ancora visto nulla in Objective-C da confrontare (ad esempio) con la fonte fitness .

Non so davvero se l'overhead sia trascurabile o meno. Ma, preferirei di progettare un sistema per essere facilmente comprensibile e mantenibile prima , e che normalmente significa piccolo, metodi e classi focalizzata. Questo aiuterà anche con la successiva ottimizzazione del codice (solo perché il codice è più gestibile). Inoltre, è importante profilare il codice per trovare veri e propri colli di bottiglia, che potrebbero anche non essere correlati al sovraccarico della chiamata del metodo. Se si eseguono operazioni fuori processo (ad es. Chiamate a database, rete, file system), queste tendono comunque a dominare il runtime del programma.

Ma, come al solito, il tuo chilometraggio può variare ...

La stragrande maggioranza del codice non sarà critica per le prestazioni in nessuna applicazione, quindi anche se l'overhead del metodo fosse significativo rispetto ad altre lingue, l'approccio ottimale sarebbe comunque quello di avere molti piccoli metodi nella maggior parte dei luoghi e incorporare solo quelli che profilano ha dimostrato di essere critico per le prestazioni.

Certo, ci sono molte persone che non sanno come ottimizzare in modo corretto, e di quelle che alcuni potrebbero conoscere il metodo overhead e impegnarsi in atti di ottimizzazione prematura globale, ma non credo che il gruppo sia abbastanza grande da avere un impatto significativo sull'ecosistema Objective-C.

Metodi e classi di grandi dimensioni hanno molte più probabilità di essere il lavoro di un folto gruppo di persone che non sanno o si preoccupano di profiler, metodi generali o design adeguato e che tenderanno a produrre Big Balls of Mud in qualsiasi lingua. E sì, alcune di queste persone lavorano su basi di codice di alto profilo nelle principali società di software.