Зберігати мої заняття та методи якомога менше?

20

Кілька днів тому я розмовляв із кандидатом кандидатів технічних наук із програмного забезпечення, і в якийсь момент вона сказала мені:

Зберігайте свої заняття та методи якомога менше

І мені цікаво, чи це завжди хороша практика.

Я маю на увазі, наприклад, чи гідно мати клас із 2 аттибутами в ньому? Наприклад, у деяких методах мені потрібні пари цілих чисел. Чи потрібно писати клас "PairOfIntgers"?

Чи міг такий спосіб мислення "зламати" код занадто багато?

code-quality coding-style

— Флоренц Целай
джерело

10

Це повинно бути"As small as possible, but no smaller."

— StuperUser

"Я маю на увазі, наприклад, чи гідно мати клас із 2 аттебутами в ньому?" - Це може бути, пошук "Примітивної одержимості" (наприклад, jamesshore.com/Blog/PrimitiveObsession.html )

— Torsten

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

— Келвін

23

У цій пораді є зерно істини, але в ІМХО це не дуже добре виражено, тому легко неправильно зрозуміти та / або довестись до дурної крайності. У будь-якому випадку, це має бути правилом, а не жорстким законом. І завжди слід наводити в таких правилах пункт "в розумних межах" або "але не забудьте використовувати здоровий глузд" :-)

Зерно істини полягає в тому, що на практиці заняття та методи завжди мають тенденцію до зростання від природи, а не до скорочення . Тут виправлено помилку, трохи розширення функції там, обробка спеціального випадку там ... і вуаля, ваш колись охайний і маленький клас починає розквітати. З часом ваш код майже неминуче перетворюється на жахливе безладдя спагетті - якщо ви не ведете активну боротьбу з цією тенденцією за допомогою рефакторингу . Рефакторинг майже завжди створює багато менших класів / методів з кількох великих. Але звичайно, є мінімальним обмеженням мініатюризації. Сенс рефакторингу - не мати менших класів і методів самі по собі, а зробити свій код більш чистим, простіше зрозуміти та підтримувати. У певний момент зменшення читання Ваших методів / занять починає зменшувати читабельність, а не збільшувати її. Прагніть до цього оптимуму. Це розмита і рухома цільова область, тому вам не потрібно вдарятись по ній. Просто трохи вдосконалюйте код, коли ви помічаєте з ним якусь проблему .

— Петер Тьорк
джерело

1

безумовно, правило не сліпо слідувати, занадто багато крихітних класів набагато гірше, ніж кілька великих класів більшу частину часу.

— Рятал

4

Моє особисте правило: якщо ви не можете побачити цілу реалізацію методу на екрані, рефактор.

— Дан Рей

6

@DanRay, так, я раніше мав те саме правило, поки не прочитав « Чистий код» . Це було досить шоком, але поступово змусив мій оптимум зійти приблизно на 10 ліній.

— Péter Török

2

Чистий кодекс ІМО жахливий у своїй крайності щодо малих методів. Проблема полягає в тому, що коли методів буде менше, їх буде більше. Звичайно, занадто довгі методи занадто довгі, але, схоже, Боб Мартін вважає за краще 10 однорядних методів над 1 10-рядковим (таким чином, фактично той самий код займає приблизно 5 разів більше місця на екрані). Можливо, це задумано як якийсь навчальний трюк, я не можу повірити, що хтось насправді вважає, що код у цій книзі є корисним.

— Joonas Pulakaka

5

@JoonasPulakka - Скажімо, я ніколи не читав методу і думав: "Я б хотів, щоб цей метод зробив більше". Скорочуючи методи, ви можете писати дуже описові назви методів, які часто можуть усунути необхідність повністю читати тіло методу. Я знайшов поради в « Чистому кодексі» дуже розумними. Нам доведеться просто погодитися не погодитися. :)

— Девід Харкнесс

9

Тут важливіше наголосити на створенні хороших абстракцій . Невеликі класи , які зв'язані слабко і мають високу згуртованість, є результатом хороших абстракцій .

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

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

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

І так само, як остаточна примітка ... незалежно від того, наскільки хороший студент ви ... для розуміння ООП та хороших абстракцій та коли ними користуватися, потрібен досвід. Вам потрібно написати поганий код і пройти через біль, щоб зберегти його. Потрібно бачити, як інші пишуть хороший код, щоб накопичити свої знання про те, що таке «добре» і що буде проблемою внизу… Тому не б’йте себе, якщо ви просто не отримаєте цього відразу.

— c_maker
джерело

2

Анти-модель "Об'єкт Бога" - це те, на що вона, мабуть, натякає. Я схиляюсь до думки, що якщо в описі класу я є "і", я повинен мати два класи. Якщо у методі / функції у мене більше десяти рядків коду, я повинен розбити його. Що стосується піратського кодексу, це більше вказівки, ніж правила.

— Сардатріон - Відновлення Моніки
джерело

2

В об'єктно-орієнтованому програмуванні принцип єдиної відповідальності зазначає, що кожен об'єкт повинен мати єдину відповідальність, і що відповідальність повинна бути повністю інкапсульована класом. Зазвичай ви робите більше, ніж ваш клас занадто великий. У вашому випадку клас - це просто клас даних, який містить дані, що цілком нормально. Не слід називати клас PairOfInteger. Що описує цілі числа? Залежно від вашого сценарію також може бути достатнім кортеж (як у C #). І ви, можливо, захочете подумати над підказкою замість класу.

Постарайтеся провести вас на заняттях малим. А методів ще менше. Може, 10 ліній?!? В даний час я намагаюся використовувати дизайн дизайну та компоненти на основі подій, які, здається, допомагають проводити заняття невеликими. Спочатку я хвилювався потрапити до багатьох занять, але це справді працює !!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

— ККТ
джерело

2

Зробіть речі максимально простими, але не простішими. Це правило, яке я намагаюся пройти. Іноді, клас насправді має сенс робити те, що суворо кажучи, становить більше ніж одне, якщо ці речі пов'язані з якоюсь загальною темою . Подивіться на .NET; є тонни класів, які реалізують велику кількість інтерфейсів, кожен зі своїм списком необхідних членів. Метод може закінчитися тим, що він повинен стати дещо довгим, якщо він зробить щось складне з низкою проміжних кроків, які взаємопов'язані між собою і, отже, не дуже добре піддаються подальшій рефакторингу. (Рефакторинг, щоб тримати методи короткими, в кінцевому рахунку повинен стосуватися читабельності та ремонтопридатності; якщо довгий метод є більш читабельним та / або ремонтопридатним, ніж короткий, все інше рівне, я візьму довгий один будь-який день.)

На мою думку, лише "зробити заняття та методи якомога меншими" - це неправильно. Справжньою проблемою є, як зазначає @c_maker, забезпечити хороші абстракції. Ваш приклад згрупування двох чисел разом чудовий, наприклад, якщо ви працюєте над реалізацією складної арифметики чисел або якщо в системі Unix вам потрібно посилатися на контекст користувача / групи. Дуже мало сенсу, якщо цифри представляють, скажімо, ідентифікатор рахунка-фактури та ідентифікатор товару, який потрібно додати до цієї накладної.

— CVn
джерело

0

Це нормальна порада, але її потрібно реалізовувати дещо розумно. Однозначно не слідкуйте за цим сліпо.

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

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

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

— Алан Делімон
джерело

Ніколи не робіть методів менше, а слідуйте за SRP, і це автоматично зробить роботу.

— Vinay Prajapati

0

Дядько Боб каже, що ви повинні переробляти / розділяти / витягувати свої методи, поки неможливо зробити їх меншими . Зазвичай це закінчується наявністю декількох методів з 3 або 4 рядками кожен. Коли ви отримуєте занадто багато методів, вам доведеться робити більше занять.

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

І завжди легше зрозуміти менші класи. Вперед, читайте "Чистий код"

— Пітер Кофлер
джерело