Здравствуйте, Sinix, Вы писали:
S> Ну и наконец универсальный вариант: добавляем имя отчёта к имени класса. Это стандартный подход для классов параметров/форм и тыды. Например, IncomeReport | IncomeReportParameters | IncomeReportUI etc.
И для верности разнести их в отдельные неймспейсы
Здравствуйте, e.thrash, Вы писали:
ET>Насколько это нормально? ET>Пример: есть куча сложных однотипных отчетов, в разных разрезах под которые создаются внутренние классы, чтобы группировать данные. ET>Или же лучше добавлять к названию класса название отчета, чтобы не дублировались названия классов в разных неймспейсах?
Если классы используются _только_ в отчётах, то ничего не мешает оформить их как nested type. Для этого особенно удобны partial-классы: основная логика в одном файле, вспомогательные типы — в другом.
Если такой вариант не подходит, но одноимённые типы _точно_ не будут использоваться одновременно в одном куске кода — заводите для каждого отчёта свой namespace.
Ну и наконец универсальный вариант: добавляем имя отчёта к имени класса. Это стандартный подход для классов параметров/форм и тыды. Например, IncomeReport | IncomeReportParameters | IncomeReportUI etc.
Насколько это нормально?
Пример: есть куча сложных однотипных отчетов, в разных разрезах под которые создаются внутренние классы, чтобы группировать данные.
Или же лучше добавлять к названию класса название отчета, чтобы не дублировались названия классов в разных неймспейсах?
Здравствуйте, e.thrash, Вы писали:
ET>Насколько это нормально? ET>Пример: есть куча сложных однотипных отчетов, в разных разрезах под которые создаются внутренние классы, чтобы группировать данные. ET>Или же лучше добавлять к названию класса название отчета, чтобы не дублировались названия классов в разных неймспейсах?
Я думал, пространства имён для того и нужны, чтобы случайно на конфликт имён не напороться.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
