Запрещать пользователям создавать объекты, но разрешать некоторые классы

Question

Запрещать пользователям создавать объекты, но разрешать некоторые классы

0

У меня есть следующие два класса.

Class A
{
   proctected:
      A(){}
};

Class B
{
    push_new_A_into_v();
    vector<A> v;    
};

Функция

push_new_A_into_v();

не будет компилироваться, поскольку конструктор защищен. Сделать B наследовать от A не поможет, поскольку метод создает совершенно новый A (почему защищенный конструктор создает ошибку этого кода?).

Причина, по которой конструктор A защищен, заключается в том, чтобы сделать пользователей неспособными создать объект типа A.

Как я могу заставить этот метод работать, пока пользователи все еще не могут создавать объекты типа A?

Niclas Jonsson 09 янв. 2015, в 15:19

Источник

0

Сделать класс B другом?
Some programmer dude 09 янв. 2015, в 13:26
0

proctected: должны быть protected:
HolyBlackCat 09 янв. 2015, в 13:27
0

Зачем вам нужен конструктор для защиты? Вам это нужно как абстрактный класс? или вы просто хотите контролировать, кто к нему обращается?
Pedrom 09 янв. 2015, в 13:58
0

«Причина, по которой конструктор А защищен, заключается в том, что пользователи не могут создать объект типа А.» Пользователь должен иметь возможность создавать объекты типа B, но не типа A.
Niclas Jonsson 09 янв. 2015, в 14:02

Показать ещё 2 комментария

Теги:

c++

class

inheritance

2 ответа

2

class A {
    friend class B;
    ...

user2913094 09 янв. 2015, в 11:26

0

Я слышал, что этого друга следует избегать, но, возможно, я ошибаюсь! Если я сделаю B другом, то все в классе A может быть приватным, а не защищенным?
Niclas Jonsson 09 янв. 2015, в 13:34
0

конечно, если возможно, подумайте о том, чтобы сделать конструктор частным, поскольку это предотвращает создание производным классом класса A. Однако отношение « friend полностью доверяет. B сможет увидеть A. Если это не нужно, см. Другой ответ - маркер конструкции, связывающий только конкретный конструктор A с B.
Richard Hodges 09 янв. 2015, в 13:52
0

@ user1991779 Ключевое слово friend ломает модификатор доступа, добавляя исключения, и программисты OO пуристов рекомендуют избегать его использования. Обсуждение, использовать ли его или нет, было бы похоже на то, как не использовать goto. Мое личное мнение заключается в том, что если вы знаете, что делаете, просто используйте это :)
Pedrom 09 янв. 2015, в 13:54

Показать ещё 1 комментарий

Ещё вопросы

Зачем вам нужен конструктор для защиты? Вам это нужно как абстрактный класс? или вы просто хотите контролировать, кто к нему обращается?
«Причина, по которой конструктор А защищен, заключается в том, что пользователи не могут создать объект типа А.» Пользователь должен иметь возможность создавать объекты типа B, но не типа A.
Я слышал, что этого друга следует избегать, но, возможно, я ошибаюсь! Если я сделаю B другом, то все в классе A может быть приватным, а не защищенным?
конечно, если возможно, подумайте о том, чтобы сделать конструктор частным, поскольку это предотвращает создание производным классом класса A. Однако отношение « friend полностью доверяет. B сможет увидеть A. Если это не нужно, см. Другой ответ - маркер конструкции, связывающий только конкретный конструктор A с B.
@ user1991779 Ключевое слово friend ломает модификатор доступа, добавляя исключения, и программисты OO пуристов рекомендуют избегать его использования. Обсуждение, использовать ли его или нет, было бы похоже на то, как не использовать goto. Мое личное мнение заключается в том, что если вы знаете, что делаете, просто используйте это :)

ComicSansMS · Accepted Answer · 2015-01-09T11-40-00.000Z

В дополнение к user2913094 ответ:

Если дать B полную дружбу, чтобы разрешить строительство, кажется неприемлемым, вы можете добавить конструктор, для которого требуется конструкционный токен, который может быть получен только B:

class A {
public:
    class ConstructionToken {
    private:
        ConstructionToken();
        friend class B;
    };

    A(ConstructionToken const&);
protected:
    A();
};

Обратите внимание, что маркер класс совершенно пуст, но так как только B может получить доступ к своему частному конструктору, что существенно препятствует пользователю вызова A открытый конструктору напрямую.

Это позволяет использовать более мелкозернистый контроль доступа, но имеет тот недостаток, что для этого требуется ввести дополнительную конструкторскую перегрузку на A

Это работало отлично, пока мне не нужно было иметь А в паре. Тогда классу A нужен конструктор по умолчанию!