C++ позволяет изменять уровень доступа к членам в производном классе в любую сторону, Java — только в сторону повышения уровня доступа, а C# — не позволяет вообще.

Понятно, что этим Java обеспечивает возможность рассматривать любой объект производного класса как объект базового класса, C++ — свободу программиста, а вот почему C# не позволяет изменять уровень доступа в сторону повышения, мне не ясно.

Кроме того было бы интересно узнать, как осмысленно можно применить понижение (в C++) и повышение (в C++ и Java) уровня доступа?

I> а C# — не позволяет вообще.
Почему? Вроде позволяет...

igna wrote:
> C++ позволяет изменять уровень доступа к членам в производном классе в
> любую сторону
Не совсем так. В С++ механизмы контроля доступа и виртуальных функций —
независимы.

Поэтому можно делать так:

class jam_rule
{
...
public:
    //Invoke rule.
    void invoke(jam_frame *frame, jam_list *res)
    {
        checkParams(frame); //Проверить параметры вызова
        do_invoke(frame,res);
    }

private:
    virtual void do_invoke(jam_frame *frame,jam_list *res)=0;
};

class native_rule : public jam_rule
{
...
private:
    virtual void do_invoke(jam_frame *frame,jam_list *res)
    {
        ...
    }
};

class saved_rule : public jam_rule
{
...
private:
    virtual void do_invoke(jam_frame *frame,jam_list *res)
    {
        ...
    }
};

То есть клиенты не могут вызвать напрямую виртуальную функцию, которая
должна работать в контролируемом окружении.

Более подробно: http://www.ddj.com/dept/cpp/184403760

Здравствуйте, igna, Вы писали:

I>Кроме того было бы интересно узнать, как осмысленно можно применить понижение (в C++) и повышение (в C++ и Java) уровня доступа?

Джава:
java.lang.Object(), метод clone() имеет модификатор доступа protected ==> если мы хотим предоставить клиенту, работающему с объектом нашего класса(неявно унаследованного от Object), возможность получить копию нашего объекта с помощью интерфейса, предусматриваемого стандартной библиотекой(clone()), мы должны переопределить этот метод с повышением модификатора доступа. Т.е. если клент видит, что в нашем классе присутствует public clone(), он знает, что создатель класса позаботился о правильной реализации клонирования. Конечно, альтернативой всему этому выступает написание метода типа makeClone() и забивание на Object.clone(), но другого применения повышения модификатора доступа не знаю

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Почему? Вроде позволяет...

А тут (см. ниже) о чем?:

17.5.4 Override methods

. . .

• The override declaration and the overridden base method have the same declared accessibility. In other
words, an override declaration cannot change the accessibility of the virtual method.

. . .

(C# Language Specification, 3rd Edition / June 2005)

Здравствуйте, Cyberax, Вы писали:

C>Не совсем так. В С++ механизмы контроля доступа и виртуальных функций — независимы.

Я вот о чем:

class B {
    public:
        void f() {}
    protected:
        void g() {}
    private:
        void h() {}
};

class D1 : public B {
    public:
        void g() {}
    protected:
        void h() {}
    private:
        void f() {}
};

class D2 : public B {
    public:
        void h() {}
    protected:
        void f() {}
    private:
        void g() {}
};

Забыл virtual:

class B {
    public:
        void virtual f() {}
    protected:
        void virtual g() {}
    private:
        void virtual h() {}
};

class D1 : public B {
    public:
        void virtual g() {}
    protected:
        void virtual h() {}
    private:
        void virtual f() {}
};

class D2 : public B {
    public:
        void virtual h() {}
    protected:
        void virtual f() {}
    private:
        void virtual g() {}
};

N_C>>Почему? Вроде позволяет...
I>А тут (см. ниже) о чем?:
I>

I>• The override declaration and the overridden base method have the same declared accessibility. In other
I>words, an override declaration cannot change the accessibility of the virtual method.

Так это идет речь о виртуальных методах. А в обычных — пожалуйста — переопределяй, как хочешь.

public class Class1
{
    protected void qqq()
    {
    }
}

public class Class2 : Class1
{
    public new void qqq()
    {
    }
}

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Так это идет речь о виртуальных методах. А в обычных — пожалуйста — переопределяй, как хочешь.

При помощи new можно и виртуальный "переопределить":

public class Class1
{
    protected virtual void qqq()
    {
    }
}

public class Class2 : Class1
{
    public virtual new void qqq()
    {
    }
}

I>При помощи new можно и виртуальный "переопределить":
Но по сути это же будет переопределение. Чем грозит переопределение через new в невиртуальных функциях?

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>Но по сути это же будет переопределение.

Сокрытие.

N_C>>Но по сути это же будет переопределение.
I>Сокрытие.
С такой точки зрения, тогда C# вообще не позволяет переопределять методы, за исключением виртуальных.
Хотя MSDN говорит:

Hiding an inherited member means that the derived version of the member replaces the base-class version.

Значит все-таки метод заменяет базовый метод...

igna wrote:
> C>Не совсем так. В С++ механизмы контроля доступа и виртуальных функций
> — независимы.
> Я вот о чем
Ну так я именно это и имею в виду. В С++ биндинг виртуальных функций
идет по имени (и не включает в себя контроль доступа).

А почему "C++ позволяет изменять уровень доступа к членам в производном классе в любую сторону" это "не совсем так"?

Здравствуйте, Nikolay_Ch, Вы писали:

N_C>С такой точки зрения, тогда C# вообще не позволяет переопределять методы, за исключением виртуальных.

Конечно.

N_C>Хотя MSDN говорит:

Hiding an inherited member means that the derived version of the member replaces the base-class version.

N_C>Значит все-таки метод заменяет базовый метод...

"Заменяет" не значит "переопределяет".

igna wrote:
> А почему "C++ позволяет изменять уровень доступа к членам в производном
> классе в любую сторону" это "не совсем так"?
Он не меняет доступ — он просто на него не смотрит

Здравствуйте, Cyberax, Вы писали:

>> А почему "C++ позволяет изменять уровень доступа к членам в производном классе в любую сторону" это "не совсем так"?

C>Он не меняет доступ — он просто на него не смотрит

И фраза вроде "The access of a member of a base class can be changed in the derived class" не имеет смысла?

Здравствуйте, igna, Вы писали:

<...>

Я думал ты об этом:

class A {
public:
    void f() {}
};

class B: public A {
private:
    using A::f;
};

int main()
{
    B b;
    b.f();       // Ошибка, доступ к приватному члену
    ((A&)b).f(); // ОК, отсюда смонительная польза возможности понижения уровня доступа к производных классах, 
                 // раз это все равно можно обойти при желании
}

Кстати к Java еще можно добавить Delphi, он тоже позволяет только повышать уровень доступа.

Здравствуйте, bolshik, Вы писали:

B>Джава:
B>java.lang.Object(), метод clone() имеет модификатор доступа protected ==> если мы хотим предоставить клиенту, работающему с объектом нашего класса(неявно унаследованного от Object), возможность получить копию нашего объекта с помощью интерфейса, предусматриваемого стандартной библиотекой(clone()), мы должны переопределить этот метод с повышением модификатора доступа. Т.е. если клент видит, что в нашем классе присутствует public clone(), он знает, что создатель класса позаботился о правильной реализации клонирования. Конечно, альтернативой всему этому выступает написание метода типа makeClone() и забивание на Object.clone(), но другого применения повышения модификатора доступа не знаю

С Java плохо знаком, но вроде у метода clone есть и еще одна особенность — он кидает исключение CloneNotSupportedException, если поддержка клонирования актуальным классом объекта не поддерживается. Зачем спрашивается такая двойная защита — через уровень доступа и исключения?