Objektif-c'nin yöntem yükü 'birçok küçük yöntem' tasarım yaklaşımını tavsiye edilemez kılıyor mu?

Genelde diğerlerinin yanı sıra Temiz Kod'da Bob Martin tarafından önerilen küçük yöntemleri kullanmayı tercih ederim . Ayrıca, Objective-C'nin iç mesajlarını, mesaj dağıtımının nasıl çalıştığı hakkında en azından biraz fikir sahibi olacak kadar okudum ( barbekü serisi bu konuda özellikle bilgilendirici).

Erken optimizasyon endişeleri olsa da, Objective-c'nin objc_msgSend ile yaptığı tüm çalışmaların pratik anlamda 'birçok küçük yöntem' yaklaşımının Objective-C projeleri için tavsiye edilemeyecek kadar önemli olup olmadığını bilmek istiyorum.

Ampirik bulgular özellikle açıktır (belki bir ara kendimi test edeceğim). Büyük objektif-c projeleri yazmış olan herkesin deneyimi de harika olurdu.

açıklama

Sorunun genel tonu kasıtlıdır. Belirli uygulamaların performans ayarını sormuyorum (bu yüzden SO yerine burada soruyorum), ancak Objective-C'nin dil özelliklerinin belirli bir tasarım yaklaşımını caydırıp caydırmadığı hakkında daha fazla bilgi istiyorum. Apple'dan ve diğer partilerden (github vb.) Gördüğüm kodun çoğunun büyük yöntemlere (ve sınıflara) eğilimli olduğunu gözlemledim ve bunun dil nedeniyle akan bir önyargı olup olmadığını merak ediyorum kendisi. Tabii yanlış kodu okumuş olabilirim, ya da varsa eğilime yol açan teknik faktörlerden ziyade kültürel olabilir.

(Değeri için şu anda Objective-C yazıyorum ve küçük yöntemler kullanıyorum)

Daha fazla talep

Verilen her iki yanıta da katılıyorum. İstediğim bir başka şey, birisinin beni (umarım önemli olan) açık kaynaklı (veya başka bir şekilde görünür) Objective-C kod tabanına güzel kısa yöntemler (ve küçük sınıflar) kullanmasıdır. Objective-C'de henüz (örneğin) fitness kaynağıyla karşılaştırılacak bir şey görmedim .

Tepegenin ihmal edilebilir olup olmadığını gerçekten bilmiyorum. Ama, kolayca anlaşılabilir ve olmak için bir sistem tasarlamayı tercih ediyorum sürdürülebilir birinci ve normalde küçük anlamına gelir, yöntem ve sınıfları duruldu. Bu, sonraki kod ayarlamasına da yardımcı olacaktır (sadece kod daha sürdürülebilir olduğu için). Ayrıca, yöntem çağrısı yükü ile ilgili bile olmayabilecek gerçek darboğazları bulmak için kodu profillemek önemlidir. Herhangi bir işlem dışı işlem yaparsanız (örneğin, veritabanına, ağa, dosya sistemine yapılan çağrılar), bunlar yine de programın çalışma zamanına hâkim olma eğilimindedir.

Ancak, her zamanki gibi, kilometreniz değişebilir ...

Kodun büyük çoğunluğu herhangi bir uygulamada performans açısından kritik olmayacaktır , bu nedenle yöntem yükü diğer dillerle karşılaştırıldığında önemli olsa bile, optimal yaklaşım hala birçok yerde birçok küçük yönteme sahip olmak ve sadece profilleme performans açısından kritik öneme sahip.

Tabii ki, düzgün bir şekilde nasıl optimize edileceğini bilmeyen birçok insan var ve bunlardan bazıları yöntem yükünü bilebilir ve küresel erken optimizasyon eylemlerine girebilir, ancak grubun önemli bir etkiye sahip olacak kadar büyük olduğuna inanmıyorum. Objective-C ekosisteminde.

Büyük yöntemler ve sınıflar biliyor ya profilers, yöntem yükü hakkında bakım hiçbir şey insanların büyük bir grup eseri olması çok daha muhtemeldir veya uygun tasarımı ve kim üretmek eğiliminde olacaktır Çamur Big Balls içinde herhangi bir dilde. Ve evet, bu insanların bazıları büyük yazılım şirketlerinde yüksek profilli kod tabanlarında çalışıyor.