Is [protected and/or internal] to be avoided?

[Jeremy S.]

Just getting into OOP here...
I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation. The way it
was presented was something like, "having a protected member implies a high
degree of trust between the base class and any derived classes - because the
derived classes have unrestricted or uncontrolled access to the protected
variable."

I now have a situation where I have a few member variables and methods that
need to be called by derived classes "as is" - so no apparent need [apparent
to me anyway] to make them abstract or virtual as the derived classes have
no need to modify their behavior (speaking of the methods in particular).
This seems to be a perfectly reasonable use of 'protected' scope. Am I
missing something? Or would most of you just shrug this off and say "very
well then."

Thanks.

[Jon Skeet [C# MVP]]

Jeremy S. <[e-mail] :

Just getting into OOP here...
I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation. The way it
was presented was something like, "having a protected member implies a high
degree of trust between the base class and any derived classes - because the
derived classes have unrestricted or uncontrolled access to the protected
variable."

I now have a situation where I have a few member variables and methods that
need to be called by derived classes "as is" - so no apparent need [apparent
to me anyway] to make them abstract or virtual as the derived classes have
no need to modify their behavior (speaking of the methods in particular).
This seems to be a perfectly reasonable use of 'protected' scope. Am I
missing something? Or would most of you just shrug this off and say "very
well then."

It's perfectly reasonable to have protected/internal members in general
- but (IMO) not variables. Internal properties, methods and events are
fine - but I always keep variables private.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[rossum]

On Tue, 18 Sep 2007 10:45:31 -0700, "Jeremy S." <[e-mail] :

>Just getting into OOP here...
I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation.

Your source was correct.

>The way it
was presented was something like, "having a protected member implies a high
degree of trust between the base class and any derived classes - because the
derived classes have unrestricted or uncontrolled access to the protected
variable."

A good reason.

>
I now have a situation where I have a few member variables and methods that
need to be called by derived classes "as is" - so no apparent need [apparent
to me anyway] to make them abstract or virtual as the derived classes have
no need to modify their behavior (speaking of the methods in particular).
This seems to be a perfectly reasonable use of 'protected' scope. Am I
missing something? Or would most of you just shrug this off and say "very
well then."

Thanks.

There is no problem at all with making methods protected or internal.
For your member variables make them private and set up a
protected/internal property to allow access.

rossum

[Ignacio Machin \( .NET/ C# MVP \)]

"Jeremy S." <[e-mail] in message
news:e$******** ********@TK2MSF TNGP05.phx.gbl. ..

Just getting into OOP here...
I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation.

Where did u read that?
Nothing farest from the truth.

The way it

was presented was something like, "having a protected member implies a
high degree of trust between the base class and any derived classes -
because the derived classes have unrestricted or uncontrolled access to
the protected variable."

That's correct (the part about unrestricted) but I fail to see something bad
on that.
In case you do not want the variable accesible mark it as private and then
create a protected property

[Jeremy S.]

>Just getting into OOP here...

>I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation.

Where did u read that?
Nothing farest from the truth.

I don't recall the source that I clearly recall mentioning the bit about
violating encapsulation.. .. probably on the net somewhere.

But I did take a quick look through some reference books I have handy just
to see if it was perhaps one of them, and I came across something similar:
The book is Framework Design Guidelines -

Page 165: "... Anyone is able to subclass an unsealed class and access
protected members, and so all the same defensive coding practices used for
public memers apply to protected members as well."

Page 166 (Brad Abrams): "... we consider protected and public to be roughly
equivalent. We generally do the same level of review and error checking in
protected APIs as we do in public APIs as they can be called form any code
that just happens to subclass.

---

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

The key in the book you cite is that the class is unsealed. Someone who
recieves the dll may extend your class in an unforseen way. Unless you
intend an external developer to extend your class, mark it sealed.

"Jeremy S." wrote:

Just getting into OOP here...
I remember reading somewhere that having protected and/or internal member
variables is to generally be avoided or potentially a "bad thing" because
having such members violates the OOP principle of encapsulation.

Where did u read that?
Nothing farest from the truth.

I don't recall the source that I clearly recall mentioning the bit about
violating encapsulation.. .. probably on the net somewhere.

But I did take a quick look through some reference books I have handy just
to see if it was perhaps one of them, and I came across something similar:
The book is Framework Design Guidelines -

Page 165: "... Anyone is able to subclass an unsealed class and access
protected members, and so all the same defensive coding practices used for
public memers apply to protected members as well."

Page 166 (Brad Abrams): "... we consider protected and public to be roughly
equivalent. We generally do the same level of review and error checking in
protected APIs as we do in public APIs as they can be called form any code
that just happens to subclass.

---

[Ben Voigt [C++ MVP]]

"Jeremy S." <[e-mail] in message
news:eP******** ********@TK2MSF TNGP04.phx.gbl. ..

>>Just getting into OOP here...
I remember reading somewhere that having protected and/or internal
member variables is to generally be avoided or potentially a "bad thing"
because having such members violates the OOP principle of encapsulation.

Where did u read that?
Nothing farest from the truth.

I don't recall the source that I clearly recall mentioning the bit about
violating encapsulation.. .. probably on the net somewhere.

But I did take a quick look through some reference books I have handy just
to see if it was perhaps one of them, and I came across something similar:
The book is Framework Design Guidelines -

Page 165: "... Anyone is able to subclass an unsealed class and access
protected members, and so all the same defensive coding practices used for
public memers apply to protected members as well."

Page 166 (Brad Abrams): "... we consider protected and public to be
roughly equivalent. We generally do the same level of review and error
checking in protected APIs as we do in public APIs as they can be called
form any code that just happens to subclass.

That's certainly true, but it hardly implies that "protected" is any worse
than "public". In fact, since .NET enforces runtime type checking,
subclassing an unsealed class is NOT sufficient to gain access to protected
members of other runtime types (in C++ it is sufficient, but C++ can always
bypass access checks using pointer arithmetic).

[Michael S]

"Jeremy S." <[e-mail] in message
news:eP******** ********@TK2MSF TNGP04.phx.gbl. ..

>
Page 165: "... Anyone is able to subclass an unsealed class and access
protected members, and so all the same defensive coding practices used for
public memers apply to protected members as well."

Page 166 (Brad Abrams): "... we consider protected and public to be
roughly equivalent. We generally do the same level of review and error
checking in protected APIs as we do in public APIs as they can be called
form any code that just happens to subclass.

I think is a problem in Java, as that language has no keywords for
virtualness and overrides.
Hence, If extend your class, add a new method, that happens to have the same
name as one of yours,
I have just overriden your method without me even knowing.

C# would not compile, and ask me to override or reintroduce the method,
witch will probably make me rename mine, as I had no intention of overriding
yours.

Also, when you code in asp.net, all thing code-behind for a page
that you want to sport in your aspx/asmx should be protected, not public.

- Michael Starberg

[Jon Skeet [C# MVP]]

On Sep 19, 12:12 pm, "Michael S" <[e-mail] e:

I think is a problem in Java, as that language has no keywords for
virtualness and overrides.

Well, you can declare a method to be final - but it defaults to being
virtual, yes.

Hence, If extend your class, add a new method, that happens to have the same
name as one of yours,
I have just overriden your method without me even knowing.

C# would not compile, and ask me to override or reintroduce the method,
witch will probably make me rename mine, as I had no intention of overriding
yours.

In C# it would compile, but with a warning.

Also, when you code in asp.net, all thing code-behind for a page
that you want to sport in your aspx/asmx should be protected, not public.

Fortunately that improves in C# 2 with partial classes.

Jon

[Michael S]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ 50g2000hsm.goog legroups.com...

On Sep 19, 12:12 pm, "Michael S" <[e-mail] e:

>I think is a problem in Java, as that language has no keywords for
virtualness and overrides.

Well, you can declare a method to be final - but it defaults to being
virtual, yes.

Well of course.
Hehe, I wonder if 'virtual sealed' would give me a 'are-you-stupid' error?
<g>

>

>Hence, If extend your class, add a new method, that happens to have the
same
name as one of yours,
I have just overriden your method without me even knowing.

C# would not compile, and ask me to override or reintroduce the method,
witch will probably make me rename mine, as I had no intention of
overriding
yours.

In C# it would compile, but with a warning.

Ah, just tested. It gives a warning alright.

>

>Also, when you code in asp.net, all thing code-behind for a page
that you want to sport in your aspx/asmx should be protected, not public.

Fortunately that improves in C# 2 with partial classes.

This has nothing to do with partial classes.

>
Jon

- Michael Starberg