Эти два класса нарушают инкапсуляцию?

Вы сделали это самостоятельно.
Вы можете написать

class Y : public X
{
public:
    void doA()
    {
       protectedFunction();
    }
};

int main()
{
    Y y1;
    y1.doA(); 
}

Я не вижу причин беспокоиться об этом.
Защищенные функции - это кусочки многоразовой логики в дереве на наследстве. Вы можете скрыть их, если есть какая-то внутренняя логика или ограничение или как в вашем случае, вы можете разоблачить его, если вы уверены, что никому не повредит.

Я думаю, что он был сам stroustrup, который сказал, что инкапсуляция и функции целостности данных, встроенные в C ++, предназначены для того, чтобы честно были честными людьми, чтобы не остановить преступников.

Нет. защищенная функция () защищена. Вы можете свободно называть это от полученных классов, поэтому вы могли бы назвать его непосредственно от государственного члена Y и позвонить в этом государственным членом от Main ().

Если бы вы могли сделать это с помощью частного методом, был бы проблема ... (Отредактировано, чтобы быть немного понятным).

Дизайнер класса должен знать, что объявление функции элементов или переменной (хотя все переменные должны быть частными, действительно), поскольку защищена в основном такая же, как объявление об этом общественности (поскольку вы прошлите легко получить доступ к защищенным вещам). Имея в виду, заботиться о том, чтобы быть приняты при внедрении этих функций в базовом классе для учета «неожиданного» использования. Это не нарушение инкапсуляции, потому что вы можете получить доступ к нему и разоблачить его.

Защищенный - это просто более сложный способ объявления чего-либо публичного!

Нет, я не вижу проблему.

вместо с использованием , используя , вы могли бы сделать это:

class X
{
protected:
    void protectedFunction() { cout << "i am protected" ; }
};

class Y : public X
{
public:
    void protectedFunction() { X::protectedFunction(); }
};

class Y : public X
{
public:
    void protectedFunction() {
       X::protectedFunction();
    }
};

После того, как метод защищен, он предлагается к получению классов, чтобы сделать это они хотят. Намерение для Декларации не изменяло унаследованные методы доступа, а скорее избегая проблем с помощью метода, скрывающейся (где общественный метод в x будет скрыт в типе Y Если определена другая перегрузка).

Теперь это факт, что из-за языковых правил его можно использовать для изменения уровня доступа для «использованных» методов, как в вашем примере, но это не открывает никакой дыры в системе. В конце концов, полученные классы не могут сделать ничего не более того, что они могли сделать раньше.

Если фактический вопрос заключается в том, является ли конкретное использование нарушением инкапсуляции с точки зрения дизайна (где дизайн здесь - это дизайн приложений, а не дизайн языка), то, скорее всего, да. Точно так же, как изготовление внутренних данных или методов общественности. Если бы он был разработан, чтобы быть защищенным исходным дизайнером x , то шансы состоят в том, что Y не хотелось, чтобы он был публичным ... (или предлагая метод делегирования для та же цель)

Нет.

Чтобы использовать общедоступный метод, у вас должен быть экземпляр y , это не будет работать:

int main()
{
    X y1;
    y1.protectedFunction();
}

Если y в своем новом определении обнародует новый интерфейс, он находится в том, что Y. X все еще защищен.

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

Я бы спросил: «Какова была смысл охраняемого метода в первую очередь?» Был ли это метод, который должен вызывать только подклассы, или это способ, которым подклассы должны переопределять? Однако это может быть метод, который не ожидается в общем базовом классе, но, возможно, ожидается в подклассе. Клиенту базового класса они никогда не знали о том, что охраняемый метод. Создатель подкласса решил расширить контракт, и теперь, когда защищенный метод является публичным. Вопрос действительно должен быть не C ++ позволяет ему, но правильно ли у вас класс, контракт и будущие сопровождающие. Уверен, что это может быть плохой запах, но на самом деле вам нужно сделать его правильным для использования в применении.

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

В целом, хотя для безопасности, как упомянуто предыдущий вкладчик, вы, вероятно, хотите использовать функцию делегирования (с другим именем) в подклассе. Поэтому вместо «Get (Int)» у вас может быть «getatindex (int)» или что-то. Это позволяет вам легче рефакторизовать / защищать / абстрактно / документ, который в будущем.