Вказівки щодо простору імен та імен класу

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

Як ви структуруєте таке:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

тощо ...

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

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

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

А також Services.EventService.EventService.csвключає ім'я класу в просторі імен, що також не є корисним. Ви можете використовувати Services.Event.EventService.cs, але, звичайно, вже існує організація з такою назвою.

Це доменна модель.

Я думаю, що найбільше, що ви могли зробити для покращення простору імен тут, - це видалити Serviceзі свого EventServiceпростору імен. Я б також налаштував простори імен, щоб вони були більше подібними:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Я все ще думаю, що це могло б використати певні покращення.

Раніше мені подобалися простори імен, але сьогодні я думаю, що менше - більше. Глибоке гніздування ваших просторів імен може зробити ваш код занадто багатослівним, а розбиття речей на далеко знижує вашу здатність до спадкування. Наприклад, у вашому коді DateValidatorклас можна легко використовувати в іншому місці, тому він не повинен мати багато просторів імен над ним, оскільки сервіси, відмінні від EventService, тепер можуть скористатися класом DateValidator. Те саме стосується методів розширення. Немає часу (що я бачу), де вам потрібно було б бачити всі свої методи розширення одночасно, тому має сенс згрупувати його з тим, до чого це стосується. У цьому випадку, EventExtensionsймовірно, посилання на ваші EventService, так що логічно, вони повинні сидіти разом, на мою думку.

Чому б вам не прочитати від Загальних положень про іменування та Правила імен, від Microsoft, щоб дотримуватися універсальної моделі?

Я думаю, що формула <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]просто працює добре.

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

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

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

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

Отже, будь ласка, подумайте про те, як ваш код буде упакований у склади та компоненти, коли ви вирішите свої проблеми з простором імен!