использование декларации для открытых статических членов класса const

Question

Человек определяет много открытых статических констант:

class Human
{
public:

static const int NUM_FINGERS = 10;
static const int NUM_TOES = 10;
static const int NUM_HANDS = 2;
static const int NUM_FEET = 2;

//The rest of the human class here
};

Несвязанный класс часто использует их и должен квалифицировать их именем класса:

class Unrelated
{
public:
int SomeFunction()
{
//Many uses of Human's public static constants
return Human::NUM_FINGERS + Human::NUM_TOES + Human::NUM_HANDS + Human::NUM_FEET;
}
};

В случаепространство имен, которое вы можете:

using namespace blah;

Есть ли эквивалент для подобной ситуации?

using namespace Human; //wrong

int Unrelated::SomeFunction()
{
return NUM_FINGERS + NUM_TOES + NUM_HANDS + NUM_FEET;
}

Считается ли плохим программированием определять таким образом группу констант?

Answer 1

Предполагая, что Unrelated действительно Unrelated_but_about_Humans, вы можете просто сказать «У меня те же константы, что и Human»:

class Unrelated
{
private:
    static const int NUM_FINGERS = Human::NUM_FINGERS;
    static const int NUM_TOES = Human::NUM_TOES;
    static const int NUM_HANDS = Human::NUM_HANDS;
    static const int NUM_FEET = Human::_NUM_FEET;
}

(Замечания других ответов относительно хрупкости и т. Д. До сих пор остаются в силе)..)

Answer 2

Несвязанный класс часто использует их и должен квалифицировать их именем класса.

Что с этим не так? Подумайте об этом так: какое имя переменной лучше, nt или num_toes? Дальнейшее определение имени с помощью класса Human (или пространства имен Human, если вы измените свой класс на пространство имен) - это хорошо, а не плохо. Это помогает компилятору, помогает вам как программисту случайно столкнуться с каким-то другим именем и помогает другому человеку, который пытается понять ваш код.

Относительно имен NUM_FINGERS и т. Д. Я рекомендую не использовать ALL_CAPS. Когда-нибудь кто-нибудь напишет макрос NUM_FINGERS, который превратит ваш код в бред. Зарезервируйте имена ALL_CAPS для макросов, а затем попытайтесь избежать макросов.

Answer 3

Это зависит от ситуации.

Константы относятся к классу Human, поэтому вполне понятно, что они им "принадлежат", а использование имен в пространстве имен (Human :: NUM_ARMS) делает их использование однозначным. (Представьте себе, что произойдет, если вы введете новые классы, такие как Octopus. Вы бы использовали Octopus :: NUM_ARMS, что было бы 8, а не 2. Слава Богу за локализованные имена классов / пространств имен!)

Конечно, в ситуации Human / Octopus вы можете пересмотреть использование констант и вместо этого использовать класс / интерфейс Animal с виртуальным методом GetNumArms (), который каждый может переопределить. Это позволит вашему клиентскому коду слабо сочетаться с человеком и осьминогом и хорошо работать для обоих типов животных. Это позволило бы основным константам быть закрытыми для каждого из этих классов.

Или, если вы пишете код в другом направлении, подумайте, что вычисляет внешний класс. Чьей ответственностью должен быть этот расчет? Возможно, вам следует добавить расчет к классу людей (например, Human::GetNumLimbs(), Human::GetNumBodyParts())

Наконец, мы все перешли с 1970-х годов, поэтому я бы порекомендовал использовать более удобочитаемый стиль для констант (например, Human::cNumFeet вызывает гораздо меньшее кровотечение из глаз, чем Human::NUM_FEET, и его не легко принять за любые макросы, которые у вас есть)

Answer 4

Считается ли плохим программированием определять таким образом группу констант?

Действительно, Ваш второй не связанный класс использует константы из другого класса. Это тесно связанная зависимость.если по каким-либо причинам первый класс будет изменен для удаления / рефакторинга, то будут затронуты и ваши вторые классы.Избегайте такой зависимости.

Answer 5

Нет, считается неправильным программирование для выравнивания пространств имен, т.е. использование using namespace, особенно в глобальной области.Если это константа в классе X, напишите X::constant, в противном случае вы просто мешаете удобочитаемости (и рискуете назвать конфликты).