Чи часто використовувати часткові класи для досягнення «модульності»?


24

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

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

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


6
вбий його вогнем! Але якщо серйозно, чи може інша команда надати якісь цитати щодо цієї передбачуваної загальної практики?
MattDavey

1
Немає. Я впевнений, що вони димуть, але я намагаюся зробити належну ретельність, перш ніж кинути молот.
Джошуа Сміт

Яке їх міркування не робити цього постійно?
JeffO

3
Попросіть їх описати в одному реченні, що 800 методів у 135 файлах мають спільне між собою. Слід відповісти на це для будь-якого розумного та розумного класу.
Carson63000

3
@ Carson63000 "Він виконує всі необхідні функції проекту." є ваше одне речення.
Рятхал

Відповіді:


39

Це аж ніяк не гарна ідея.

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

Подивіться на це так: Якщо клас богів із 800 методами в одному файлі, де ви знаєте, де все, - це погано - і я думаю, що всі погодиться, що це так - то як можна створити клас богів з 800 методами розповсюджується на 135 файлів, де ви не знаєте, де все, можливо, є гарною справою?


1
Я в основному погоджуюся, але, думаю, можуть бути рідкісні випадки, коли вони partialможуть бути корисними навіть без згенерованого коду. Можливо, коли у вас є щось на кшталт вкладеного класу?
svick

1
@svick: Часткові заняття цікаві, але зазвичай не потрібні. Я не впевнений, чому розділення класу на окремі файли було б корисним, коли є вкладені класи. Якщо ви не хочете, щоб вкладений клас був у своєму фізичному файлі. У такому випадку ... maaaaybe це нормально. ;)
FrustratedWithFormsDesigner

5
Я іноді використовую часткові класи для явних реалізацій інтерфейсу - особливо щось на зразок System.IConvertible. Якось здається чистішим, ніж ставити масивний #region у свій клас.
MattDavey

1
Вкладений коментар до класу - це насправді гарна ідея, я про це навіть не думав. Хоча ... це має більше спільного з організацією, ніж "модульність"
Шелдон Варкентін

1
"Часткові класи існують, щоб допомогти дизайнеру форм." Правильно взагалі, але я б додав "... та інші генератори коду". Я згоден на решту вашої відповіді;)
Silas

14

Тож питання було:

Це насправді звичайна практика чи якимось чином хороша ідея?

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

Однак це питання - це червона оселедець до реальної критичної частини того, що було пропущено; оскільки ОП також має сказати про ситуацію:

(...) Хоча моя реакція кишки полягала в тому, щоб вивести її з орбіти, вони наполягають ...

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

НЕ ПОСПІШАЙТЕ!

Це ось те, що змусило мого образно кажучи монокля впасти в мою образну чашку чаю.

Я був у подібних ситуаціях, і дозвольте сказати вам: НЕ впадайте за позиви зробити це. Звичайно, ви можете кинути Nuke Hammer of Justice команди, але перш ніж це зробити, будь ласка, принижте себе за допомогою такої трохи головоломки:

Що станеться, якщо ти скажеш команді, що їхній код смокче і відторгається ?

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

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

Також покладіть себе в їх взуття, що б вони робили? Дозвольте розвеселити вас таким можливим результатом:

Член команди №1: "Отож, цей хлопець говорить нам, що ми робили це неправильно протягом останніх років".

Член команди №2 та №3: "Що за ривок".

Впливовий член групи №4: "Не хвилюйтеся про це, я просто піду до керівництва і повідомлю про це як про утиски".

Подивіться, що там зробив член впливової команди №4 ? Він пішов до управління і скоротив вашу карму в компанії. Він може бути американсько-італійським, кажучи всім не турбуватися про це, але тоді я буду расистським щодо цього.

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

Навіть якщо вам вдалося змусити купу людей відмовитися від цього, щоб «навчити команду уроку», пам’ятайте, що ви робите це досить розумним людям, які, мабуть, щось роблять. Як тільки код буде переписаний / перероблений / розібраний / що завгодно, і виникнуть проблеми, за які ви будете притягуватися до відповідальності, як ви були начальником пожеж .

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

Є й інші (значно зрілі) способи

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

  • Неінформовані - вони справді не знали, що існують інші способи, або просто не розуміли. Молодші розробники зазвичай підходять до цієї категорії, але не обов'язково. (Якщо чесно: я зустрів молодших розробників, які були б яскравішими за це.)
  • Стадо - Вони знали кращі методи, ніж використання часткових занять, але не знали, що їм дозволено.
  • The Cynic - Вони просто хочуть стверджувати, що часткові заняття - це краще, ніж ваша ідея, просто сперечаючись. Це легко зробити в натовпі, а не стояти перед натовпом.
  • The Burned - Чомусь вони не люблять створювати нові класи, швидше за все, вони сприймають це як надто складно.
  • The Time Crunched - Вони настільки зайняті, що не можуть завадити виправити свій код.
  • Бос - Вони думають: "Ну це працює; то чому б це турбувати?"
  • Ірраціональне - Добре, вони просто абсолютно божевільні.

Книга продовжується із переліком стратегій тощо, але у випадку з ОП це питання переконання. Потужність голови з фактами про анти-візерунок недостатньо.

Якщо вам подобається підвищити якість коду, принаймні дайте шанс команді-порушнику повторити і виправити власний безлад . Особисто я спробував би їх згорнути, слухаючи і задаючи провідні запитання, нехай розповість свою історію:

  • Що саме робить їх клас богів?
  • Чи стикалися вони з якимись проблемами? Чи є у них помилки? Запропонуйте правильні виправлення, не кажучи їм це робити.
  • Якщо ви користуєтеся цим класом богів як API: Чи існують простіші способи використання коду, ніж використання всієї справи? Запропонуйте простіші приклади, подивіться, як вони реагують.
  • Чи можете ви вимкнути якусь функціональність з іншою, не вимагаючи записати функцію?
  • Чи потребують вони певної підготовки? Чи можете ви переконати керівництво в тому, щоб дати їм це зробити, або пообідати зустрічами з приводу звичаїв та практик?

... і так далі. Дайте їм невеликі пропозиції, щоб вони могли рухатися вперед. Це потребує часу і знадобиться трохи змащення ліктя для офісної політики, але терпіння і наполеглива праця - це чеснота, правда?


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

6

Сторінка часткових класів і методів MSDN пропонує дві ситуації для використання часткових класів:
1. Розбити гігантський клас на кілька окремих файлів.
2. Мати місце для розміщення автоматично сформованого вихідного коду.

2 широко використовується Visual studio (наприклад, для файлів aspx та для winforms). Це розумне використання часткових класів.

1 це те, що робить ваша команда. Я б сказав, що використання часткових класів - це цілком розумний спосіб досягти модульності, коли у вас є гігантські класи, але наявність гігантських класів сама по собі нерозумна. Іншими словами, мати гігантський клас - це погана ідея, але якщо ви збираєтесь мати клас гігантів, часткові класи - це гарна ідея.

Хоча, якщо ви можете інтелектуально розділити клас на окремі файли, на яких можуть працювати різні користувачі, чи не можете ви просто розділити його на окремі класи?


+1 для "чи не можете ви просто розділити його на окремі класи?". Це саме те, що ми пропонуємо. Здається, здоровий глузд, що це повинно було бути зроблено спочатку.
Джошуа Сміт

4

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

Або переконайте їх у тому, що вони роблять неправильно, або вийдіть звідти чорт.


1

Клас корисних програм містить методи, які не можна розумно поєднувати з іншими методами для створення класу. Якщо у вас є 800+ методів, розділених на 135 файлів, мабуть, комусь вдалося знайти деякі поширені методи ...

Тільки тому, що у вас є один клас корисності, не означає, що ви не можете мати інший клас корисності.

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

І ні, це не часто (більше кількість файлів, ніж кількість вільних функцій).


0

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

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

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

Тож будьте уважні та обґрунтуйте рішення про вбивство. Також врахуйте, яке тестування буде потрібно.


0

Це ідеально з точки зору практичного дизайну, якщо 135 файлів насправді групують методи, схожі на те, що роблять традиційні класи. Це лише в середньому 6 методів на файл. Це, безумовно, не найпопулярніший або традиційний спосіб розробки проекту. Спроба змінити це просто створить купу проблем і поганої волі без жодної реальної користі. Приведення проекту у відповідність до стандартів OO створить стільки проблем, скільки їх вирішує. Зовсім інша справа, якщо кілька файлів насправді не забезпечують значущого поділу.


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

@BillK, якщо ви зачекаєте десять років, те, що ви знаєте, буде, ймовірно, поточною філософією дизайну "в".
Рятал

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

@Ryathal це не те, що "в", це те, що ти вважаєш гарним дизайном (з поважних причин), а потім, коли ти практикуєшся і вдосконалюєшся, розумієш, що це просто не така гарна ідея, як ти думав. Здається, це відбувається кожні 5 років або близько того, і колись я визнав, що це гартує мою реакцію на коментарі деяких людей, бо я розумію, що вони насправді прекрасні дизайнери, які (як і ми всі) в процесі назавжди вдосконалення нашої практики. Єдиний програміст, про який я б хвилювався, - це той, хто не думав, що зможе покращити код, написаний 5 років тому.
Білл К

0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.