Keep in mind that what we're doing is creating a new class, not
modifying the original class.  We're not making the member public,
we're creating a new public member in a new class that just happens to
have the same name as a protected member in the base class.

Would you feel better about it if the new member had a different name?

Probably diverging a bit here but... How about the subclass has a
public member the same as a protected member in the superclass but it
does something completely different?

If the subclass does everything the superclass does (ie doesn't break
any contracts) then I'd say all is well.

David

"If we can hit that bullseye, the rest of the dominoes
 will fall like a house of cards... checkmate!"
 -Zapp Brannigan, Futurama


On Wed, Aug 4, 2010 at 14:55, Arjang Assadi <[email protected]> wrote:
> On 4 August 2010 13:32, David Richards <[email protected]> wrote:
>> Wouldn't increasing access technically just be adding a member to the
>> subclass?  A member that, publicly anyway, the superclass didn't have.
> Yes, but I have seen cases where a member is declared protected and to
> access that
> a new subtype is derived with the only intention of declaring that
> protected member public!
>
> Now if that member was meant to be protected for internal use, why
> widen it's access in the decendent class?
> wouldn't it make more sense to have it public to begin with? I come
> across this somewhere as a trick being used to access a protected
> member of a class ( first time I saw this in Delphi 17 or so years ago
> ) now it has it's surfaced ugly head in C#.
>
>> What happens internally is pretty irrelevant.
> Internally yes, but from design point of view, when we compare the
> Parent and inherited class, we find the members that for some unknown
> reason at one level are meant to be protected and next shzaam! they
> are public.
> I am not concerned with security at all, just the design paradigm
> seems to be inconsistent.
>
> Of course one can argue that what if we don't have access to the
> original class and the idiot who designed it should have made it
> public. In that case increasing the access seems like the poor man's
> patch, rather than fixing the problem at it's source (pun intended).
>
> Regards
>
> Arjang
>
>
>
>>
>> In my book, decreasing is always bad.  I've seen it happen in some
>> Microsoft classes.  It was really annoying.  I can't imagine when this
>> would be a good idea.
>
> Never, as Michael pointed out it breaks polymorphisim.
>

Reply via email to