Недавно я пытался создавать части своего кода в модулях. Моя проблема заключалась в том, как назвать ее и сохранить ее так, чтобы имя/адрес в классе были бы легкими и рассказали все, что нужно знать о цели класса. Первой идеей было создание интерфейса (абстрактный класс) с именем Foo, а затем в пространстве имен Foo создавать классы, так что у меня был бы код вроде:
Foo* foo = Foo::Bar();
но мы не можем создать пространство имен и класс с тем же именем. Таким образом, другой подход заключался в том, чтобы сделать интерфейс закрывающим классом и поместить в него указанный класс (их декларации), а затем определить указанные классы:
class A {
public:
void foo() = 0;
class B;
class C;
};
class B : public A {
//
};
class C : public A {
//
};
Мне интересно, хорошая ли практика такого рода для классов и интерфейсов? Или я должен использовать что-то еще/не помню плохого именования для базового класса?
Big pro - это именование. Если - например, я использую его как систему исключений - я могу написать такой код:
Exception* exception = new Exception::IllegalArgument();
вместо:
Exception::Interface* exception = new Exception::IllegalArgument();
Но есть и большой недостаток. Я могу написать что-то вроде:
Exception::IllegalArgument::Exception::IllegalArgument::Exce... exception;
Итак, что вы думаете об этом? Является ли это okey и nver-mind этим бесконечным циклом с типами, или я должен думать о другой стратегии?
Это безразличная практика.
С этим я подразумеваю, что он не покупает вас так много, и нет действительно недостатков.
Тем не менее, норма просто объединяет их в одном пространстве имен и делается с ним.
Он "выглядит более чистым", и если вы измените иерархию там, по крайней мере, шанс, что вы это сделаете без слишком большого кровопролития.