Чи робить метод націлювання на головний метод підхід до проектування "багатьох малих методів" недоцільним?

Я, як правило, віддаю перевагу використанню невеликих методів, як рекомендував, серед інших, Боб Мартін у « Чистому кодексі» . Я також читав достатньо про внутрішні засоби Objective-C, щоб мати хоч якесь уявлення про те, як працює його відправка повідомлень ( серія bbums є особливо інформативною щодо цього).

Нечасна оптимізація стосується незважаючи на це, я хотів би знати, чи все те, що працює у Objective-c з objc_msgSend, на практиці є достатньо вагомим для того, щоб підхід «багатьох малих методів» був недоцільним для проектів Objective-C.

Емпіричні висновки особливо вітаються (можливо, я колись влаштую тест). Досвід кожного, хто написав великі об'єктивні проекти, також був би чудовим.

Уточнення

Загальний тон питання є навмисним. Я не запитую про налаштування продуктивності конкретних додатків (саме тому я прошу тут, а не про SO), а більше про те, чи мовні характеристики Objective-C відштовхують певний дизайнерський підхід. Я помітив, що більша частина коду, який я бачив від Apple, та інших сторін (на github тощо), має тенденцію до великих методів (і класів), і мені цікаво, чи це упередженість, яка прокралася через мову себе. Звичайно, я, можливо, читав неправильний код, або це може бути культурні, а не технічні фактори, які призвели до тенденції, якщо вона існує.

(Для чого це варто, я зараз пишу Objective-C і використовую невеликі методи)

Подальший запит

Я погоджуюся з обома даними відповідями. Ще одне, що я хотів би, щоб хтось вказав мені на (сподіваюсь, істотний) відкритий код (або інший вид) кодової бази даних Objective-C, яка використовує хороші короткі методи (і невеликі класи). Я ще не бачив нічого в Objective-C для порівняння (наприклад) з джерелом fitnesse .

design coding-style objective-c

— Крис
джерело

У Майка Еша є кілька приємних постів, де відображаються номери для Leopard та iOS . Я не переробив їх повністю, але здавалося б, що для кешованих IMP накладні витрати незначні, і навіть у розсилках, що потребують пошуку, це досить мало. Якщо це швидке враження правильне, може здатися, що невеликі методи можуть стояти або потрапляти на ті ж самі конструктивні підстави в ObjC, як і в будь-якій іншій мові.

— Кріс

Якщо ви хочете уникнути накладних витрат, використовуйте функції C.

— праворуч

Технічно можливо, але багато втрачено за допомогою функцій. Я би замінив лише методи функціями для цільових, чутливих до продуктивності частин коду. Я запитую тут про те, чи є накладні витрати досить проблематичними, щоб переглянути бажаний стиль кодування / дизайну.

— Кріс

Див. Вартість відправки повідомлень у Objective-C on SO для отримання гарних відповідей.

— Калеб

Чому ви не просто профіліруєте свій код у Xcode? Я розумію, що ви запитуєте в рефераті, а не в конкретному коді, але оскільки ви, мабуть, отримали якийсь код з безліччю маленьких методів, чому б не запустити його і подивитися самі?

— Калеб

Відповіді:

Я не знаю насправді, накладні витрати чи ні. Але я б вважав за краще , щоб розробити систему , яка буде легко зрозуміти і ремонтопрігодни перший , і що зазвичай означає маленький, орієнтовані методи і класи. Це навіть допоможе для подальшої настройки коду (лише тому, що код є більш ретельним). Крім того, важливо профілювати код, щоб знайти справжні вузькі місця, які можуть бути навіть не пов'язані з накладними викликами методів. Якщо ви робите якісь позапрацездатні операції (наприклад, дзвінки до бази даних, мережі, файлової системи), вони, як правило, переважають під час виконання програми.

Але, як завжди, ваш пробіг може відрізнятися ...

— Йордао
джерело

Звичайно, я погоджуюся з усім цим (див. Посилання "Дядько Боб" у запитанні). Але якщо мова не піддається взагалі до певного кращому випадку підхід до дизайну, програмісти могли б зробити інший вибір. Я не бачив особливого коду Objective-C, який би насправді дотримувався малих методів (і класів для цього підходу), і мені цікаво, чому. Додамо записку до запитання.

— Кріс

@Cris: "Я не бачив багато об'єктивного C коду, який насправді слідує маленьким методам" -> Просто цікаво: з якого коду коду ви зробили такий висновок? Я вірю в це, але я також вважаю, що це не через усвідомлення мікрооптимізації, але більшість програмістів не зосереджуються на принципах гарного дизайну та ремонту. Якщо говорити іншим способом, їх Java, C #, Ruby або будь-який інший код повинні дотримуватися тих самих практик ...

— Jordão

Так, це цілком можливо. Я не мав на увазі якоїсь конкретної бази коду; саме те, що я дивився протягом року або близько того, я працював з Objective-C. Найбільший набір коду, який я переглянув, - це матеріали з відкритим кодом групи Omni та IIRC, які мали багато великих методів. Зразок коду Apple також часто є. Але, звичайно, (а) зразок коду - це саме те, і (b) мій зразок може бути зважений до коду інтерфейсу, зокрема контролерів перегляду, і вони можуть бути закодовані по-різному від глибших шарів.

— Кріс

Переважна більшість кодів не буде критично важливою для будь-якого додатка, тому навіть якщо метод накладних витрат був суттєвим порівняно з іншими мовами, оптимальним підходом все-таки було б мати багато маленьких методів у більшості місць і вводити лише ті, що профілюють виявилося критичним для продуктивності.

Звичайно, є багато людей, які не знають, як правильно оптимізувати, і ті, хто може знати про методи накладних витрат і вступати в акти глобальної передчасної оптимізації, але я не вірю, що група досить велика, щоб мати значний вплив про екосистему Objective-C.

Великі методи і класи, набагато більш імовірно, буде роботою великої групи людей , які не знають або догляд нічого про профайлером, накладні витрати методи або належному проектуванні, і які , як правило, виробляють великі кулі з бруду в будь-якому мовою. І так, деякі з цих людей працюють над гучними кодовими базами у великих програмних компаніях.

— Майкл Боргвардт
джерело