Розщеплення на файли - скільки розщеплення?

9

Якщо я скажу, що у мене є ієрархічна структура сутності, а не складова модель. Щось на кшталт:
(Так, це складено)

Зброя -> Gun-> AutomaticGun-> MP44
Або, більш класичний приклад:
Entity-> MovableEntity-> Enemy-> WalkingEnemy

Як далеко ви б розділили вихідні / заголовкові файли для читабельності та організації? Чи найкраще піти на зразок Entity.cpp, MovableEntity.cpp, Enemy.cpp тощо, чи такий підхід, як Entity.cpp [містить Entity і MovableEntity] та Enemy.cpp [містить Enemy та WalkingEnemy], буде кращим? (Або, більш мовно, агностично, файл Enemy та файл Entity vs файл для кожного класу?)
Також це вплине на що-небудь, крім читабельності та організації?

c++ file

— Качка комуністична
джерело

1

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

— Тетрад

Хороший момент, я думаю, що можу відмовитись.

— Качка комуністична

12

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

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

Хоча чудово групувати невеликі структури та перерахунки, пов’язані з класом, у файлі одного класу . Якщо у вас є enum, який використовується лише одним класом, навіщо розділяти його на власний файл? Просто складіть їх разом. Але якщо він використовується іншим класом (тобто інший член класу має тип цього переліку), тоді настає час надати йому власний файл.

— Рікет
джерело

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

— Майк Стробель

1

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

— Качка комуністична

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

— Майк Стробель

2

Багато мов за межами C / C ++ накладають обмеження на файли. Рікет згадував Яву про "один клас на файл"; Python використовує файли як простори імен; інші мови часто копіюють дух цих.

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

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

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

Я використовував ієрархію як приклад; Я відчував, що це наголошує на тому, що я маю на увазі краще. У фактичному коді я прагну до компонентів.

— Качка комуністична