Чи доцільно створювати декілька класів у файлі .cs або кожен файл .cs має індивідуальний клас?
Наприклад:
public class Items
{
public class Animal
{
}
public class Person
{
}
public class Object
{
}
}На хвилину ухиляючись від факту, що це поганий приклад гарної архітектури, має більше ніж один клас у файлі .cs з запахом коду?
Відповіді:
Приклад, який ви подали, насправді чудовий на мій погляд. Ви оголошуєте внутрішні класи , тому їх цілком розумно зберігати в одному файлі . Єдиним способом цього було б зробити ваш Itemsклас частковим класом і розділити його на кілька файлів. Я вважаю це поганою практикою. Моя загальна політика щодо вкладених класів полягає в тому, що вони повинні бути невеликими та приватними. Є два винятки з цього:
Якщо ви сформулюєте це питання дещо інакше і запитаєте про "Чи повинен я помістити кожен простір імен - клас рівня у свій файл", то моя відповідь буде "так".
При розробці класів ми дотримуємось єдиного принципу відповідальності. Читання коду стає набагато простіше, якщо його форма слідує його семантиці, отже, розбиття файлів за класом доцільне.
З механічної точки зору, наявність файлу для кожного класу має ряд переваг. Ви можете відкривати кілька класів одночасно в різних вікнах. Це особливо важливо, оскільки жоден серйозний розробник не працює з менш ніж двома екранами. Можливість мати більше контексту перед головою означає, що я можу зберегти більше контексту в голові. (Більшість IDE дозволять вам відкривати один і той же файл двічі, але я вважаю це незручним).
Наступним важливим аспектом є управління джерелами та об'єднання. Тримаючи класи окремо, ви уникаєте великих клопотів, коли вносяться зміни до одного файлу, оскільки окремі класи потрібно змінити.
Щоб бути жорстоко чесним, будь ласка, не додайте до файлу більше одного кореневого класу. На моїй останній роботі були файли не лише з декількома класами, але з декількома просторами імен, і це поширювалося на кілька тисяч рядків коду. Дуже складно спробувати слідувати.
Якщо є класи, тісно пов'язані між собою, то або називайте свої файли аналогічно, або помістіть їх у підпапку.
Фізичний поділ файлів класу допомагає (зауважте, не кінець все-таки всім) сприяє роз'єднанню проблем і більш вільній зв'язці.
З іншого боку, ваш приклад не відображає більше одного кореневого класу. Є кілька вкладених класів (зверніть увагу: намагайтеся не робити вкладених класів нічого, але privateякщо ви можете це спроектувати), і це цілком прекрасно мати в одному файлі.
Якщо файли сильно згуртовані, наприклад, якщо це альтернатива наявності декількох дуже коротких файлів з аналогічним назвою, то це може бути хорошою ідеєю.
Наприклад, я вважаю, що при використанні Fluent NHibernate легше, якщо я зберігаю EntityіEntityMap в одному файлі, незважаючи на те, що мої інструменти можуть сказати про це.
У більшості випадків це просто ускладнює пошук занять. Використовуйте економно та обережно.
Простіше кажучи, це не так добре, як це зробити, і я скажу вам чому, трохи пізніше, коли ваше рішення стане великим, ви забудете, де такі класи, як ім'я файлу більше не буде представляти вміст, яке ім'я файлу AnimalPersonObject.cs це просто неможливо.
Впевнені, що ви зможете обійти це, скориставшись такими інструментами, як resharper, щоб перейти до типів, але 1 клас на файл (включаючи інтерфейси) справді є основою будь-якого стандарту коду, який я коли-небудь бачив, не лише в .net, а в Java та c ++ і безліч інших мов, тих, які не мають часто проблем з обслуговуванням, і ви знайдете молодших розробників, яким важко зрозуміти код.
Практично всі інструменти оптимізації коду підкажуть вам перенести класи в окремий файл, тож для мене так, це запах коду і потребує певного уникнення, щоб його нейтралізувати :)
Інша проблема полягає в тому, що з дуже великими і схожими класами в одному файлі - коли ви не можете бачити декларацію класу в будь-який час - ви можете в кінцевому підсумку ставити точки проходу в неправильному класі і цікавитись, чому вони не потрапляють ... гррр! :)