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]]

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.

 

[rossum]

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 \)]

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

 

[Larry Smith]

I remember reading somewhere that having protected and/or internal member

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

I'm actually surprised to hear that since most would disagree.

In case you do not want the variable accesible mark it as private and then
create a protected property

That's the prevailing sentiment in order to promote encapsulation.

 

[Jeremy S.]

Just getting into OOP here...

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.

---

 

[Guest]

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.

 

[Ben Voigt [C++ MVP]]

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]

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]]

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]

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?

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

Ah, just tested. It gives a warning alright.

Fortunately that improves in C# 2 with partial classes.

This has nothing to do with partial classes.

Jon

- Michael Starberg

 

[Jon Skeet [C# MVP]]

This has nothing to do with partial classes.

Yes it does - because the ASP.NET 1.0 model involved the designer page
deriving from the code-behind class.

In ASP.NET 2.0 the designer class is a partial class, as is the code-
behind class - so you don't need to make things protected in the code-
behind.

Jon

 

[Michael S]

Yes it does - because the ASP.NET 1.0 model involved the designer page
deriving from the code-behind class.

In ASP.NET 2.0 the designer class is a partial class, as is the code-
behind class - so you don't need to make things protected in the code-
behind.

Jon

Well, every thing you do dynamically must be at least protected to be
accessable in the aspx/asmx.
Even asp.net 2.0 default template have the Page_Load event protected
nowadays.

public partial class Example : System.Web.UI.Page
{
protected string caption;
protected void Page_Load(object sender, EventArgs e)
{
caption = "MyExample " + DateTime.Now.ToString();
}
}

 

[Jon Skeet [C# MVP]]

Well, every thing you do dynamically must be at least protected to be
accessable in the aspx/asmx.

Have you tried it?

Even asp.net 2.0 default template have the Page_Load event protected
nowadays.

It doesn't have to be though. I'm not sure why it makes it protected
by default, but I've just created a new web application project, added
a label, and changed its Text property in the Page_Load method. Ran
it, and all was fine. Changed the method to be private (and changed
the text), re-ran it - it was still called.

This *slightly* surprised me - I was expecting that autowiring might
require protected access, but apparently it doesn't. Even if you
needed protected access for events, that's still very different from
the .NET 1.1 model where you needed to make *everything* accessed from
the designer part protected. Partial classes have made things a lot
more sensible in this regard, IMO.

Jon

 

[Michael S]

This *slightly* surprised me - I was expecting that autowiring might
require protected access, but apparently it doesn't. Even if you
needed protected access for events, that's still very different from
the .NET 1.1 model where you needed to make *everything* accessed from
the designer part protected. Partial classes have made things a lot
more sensible in this regard, IMO.

Jon

I agree. Partial classes seemed like sugar when I first heard of it,
also, a Java-dude next to me was crying:

- First your crappy language allows for several classes interfaces in one
file,
and now it also allows for classes to span files. That is crazy!

But now that we see how it can be used, it is brilliant.

I just finished a project today that expands a typed dataset with some
methods,
and also, I needed some dynamic sql and found a nifty way via google on how
to
1) expand a TableAdaptor and sport the _adaptor as a property, and 2) also
let me temporarily
replace the sql generated by the designer with dynamic sql. Marvelous.

I call this expansion, not to confuse it with extentions in .NET 3.5.
Guess how my dear Java-friend next to me reacted when I told him about
those. =)

Anyway, what term would you use for expanding a partial class. Expansion?

Now we got specialization, implementation, expansion and extentions. C# is
getting rather complex.

- Michael Starberg

 

[Jon Skeet [C# MVP]]

I agree. Partial classes seemed like sugar when I first heard of it,
also, a Java-dude next to me was crying:

- First your crappy language allows for several classes interfaces in one
file, and now it also allows for classes to span files. That is crazy!

I have to say that although the Java way of forcing a public class to
be declared in a file with the same name is restrictive, it *does*
avoid the situation I've seen several times where it's hard to navigate
around source due to poor file naming. (VS doesn't help in this regard
either - fortunately ReSharper comes to the rescue.)

But now that we see how it can be used, it is brilliant.

Agreed. Like all features, it can be horribly abused, but for
separating generated code from manual code, it's really nice.

Anyway, what term would you use for expanding a partial class. Expansion?

Not sure what you even mean - if you mean taking a "normal" class and
splitting it into a partial class in two or more files, I'd use
"splitting" rather than "expanding".

Now we got specialization, implementation, expansion and extentions. C# is
getting rather complex.

C# 3 is *very* complex compared with C# 1. I feel sorry for those who
are asked to learn C# 3 from scratch - it's fine to learn the new
features every couple of years, but it's now a relatively big language
to learn from nothing.

 

[Michael S]

I have to say that although the Java way of forcing a public class to
be declared in a file with the same name is restrictive, it *does*
avoid the situation I've seen several times where it's hard to navigate
around source due to poor file naming. (VS doesn't help in this regard
either - fortunately ReSharper comes to the rescue.)

That is hardly a problem, even for a large project. ctrl-f does the trick.
Also, ReShaper is quite good, but won't work for large projects
as Visual Studio starts to lag bigtime.

Agreed. Like all features, it can be horribly abused, but for
separating generated code from manual code, it's really nice.

Hehe, my worst abuse was playing around with operator overloading.
I had Node, and NodeList. Adding two nodes gave you a Nodelist,
adding a NodeList with a Node was an append, adding two NodeLists was a
merge,
where duplicates was removed. All this was of course not documented.

z = a + b +c + d; // wtf is goin' on here =)

Luckely, we all saw my folly, and the operator was removed, so code turned
into

z = a.Merge(b.append(c).append(d)); // aha, get it now.

.... and the variable names was of course not z, a, b, c and d.

Not sure what you even mean - if you mean taking a "normal" class and
splitting it into a partial class in two or more files, I'd use
"splitting" rather than "expanding".

No. I am talking about how most generated code is done by partial classes.
if you create a DataSet, or with linq, a DataContext, they can be
'expanded'.

I am not talking about using extentions, but by the fact the classes are
partial,
you can add to the classes, sporting your own methods that has private
access.
Very nifty.

In the project I finished yesterday, my typed DataSet has a method called
Search,
that does all crazy dynamic things on its DataTables.
The code is not in a some Helper class, not in some DALtoDataSet class,
but part of the DataSet. It's ingenious.

C# 3 is *very* complex compared with C# 1. I feel sorry for those who
are asked to learn C# 3 from scratch - it's fine to learn the new
features every couple of years, but it's now a relatively big language
to learn from nothing.

Part of my work is to get VBers and Javaits into C#.
I am so fond of that, that I spend my free time helping people to learn to
code.
Hehe, I spend a lot of time lurking in here as well, but I seldom get to
reply,
as you guys are too fast and often gives better replies than I would. *s*

But back to C#. While complex,
I find it easy to teach C# becuase the underlying model is so clean.

When it comes to language features, they can all be abused.
But I like operator overloading, because that helps to explain why you can
add, but not substract strings.
- It has an overloaded + operator that calls .Concat().

I like how they gave us extention-methods in C# 3.0. They could have done
magic under the hood, but it seems like the C# team goes by the idiom: - If
we can do it, you should be able to do it.

Why I love C#

- Michael Starberg

 

[Jon Skeet [C# MVP]]

That is hardly a problem, even for a large project. ctrl-f does the trick.

That will find you *all* the references, unless you then start looking
for "class X" at which point you get problems if anyone's put extra
spaces in etc...

Also, ReShaper is quite good, but won't work for large projects
as Visual Studio starts to lag bigtime.

Have you tried it recently? It works fine with pretty large solutions
I've used. I do have a fast laptop admittedly, but I *love* ReSharper.

No. I am talking about how most generated code is done by partial classes.
if you create a DataSet, or with linq, a DataContext, they can be
'expanded'.

I am not talking about using extentions, but by the fact the classes are
partial,
you can add to the classes, sporting your own methods that has private
access. Very nifty.

I'd just call that adding extra members

In the project I finished yesterday, my typed DataSet has a method called
Search,
that does all crazy dynamic things on its DataTables.
The code is not in a some Helper class, not in some DALtoDataSet class,
but part of the DataSet. It's ingenious.

Yes - and the partial methods in C# 3 are rather neat too.

Part of my work is to get VBers and Javaits into C#.
I am so fond of that, that I spend my free time helping people to learn to
code.
Hehe, I spend a lot of time lurking in here as well, but I seldom get to
reply,
as you guys are too fast and often gives better replies than I would. *s*


But back to C#. While complex,
I find it easy to teach C# becuase the underlying model is so clean.

Do you normally teach C# 1, 2 or 3? Explaining generics, nullable types
etc can be quite tricky - likewise anonymous methods, lambda
expressions etc.

When it comes to language features, they can all be abused.
But I like operator overloading, because that helps to explain why you can
add, but not substract strings.

- It has an overloaded + operator that calls .Concat().

Except it actually doesn't - that particular feature is done by the C#
compiler. String doesn't overload the + operator.

I like how they gave us extention-methods in C# 3.0. They could have done
magic under the hood, but it seems like the C# team goes by the idiom: - If
we can do it, you should be able to do it.

Why I love C#

The motto at the moment seems to be something like, "If the compiler
can safely infer some information, the coder shouldn't have to specify
it." I'm starting to really like that...

 

[Michael S]

Have you tried it recently? It works fine with pretty large solutions
I've used. I do have a fast laptop admittedly, but I *love* ReSharper.

Maybe I should give it another try.
I'll install it later this afternoon. I also liked it alot,
but had to uninstall it because it slowed down Visual Studio to a halt.

I'd just call that adding extra members

I call it expanding.

Yes - and the partial methods in C# 3 are rather neat too.

I have yet had any use of them,
but I can see how they come in handy.

Do you normally teach C# 1, 2 or 3? Explaining generics, nullable types
etc can be quite tricky - likewise anonymous methods, lambda
expressions etc.

Yes, all three of them.
Well, whenever someone don't understand co/contra variance with generics,
or threading or whatever, I just redirect them to your website, - Easy!

Except it actually doesn't - that particular feature is done by the C#
compiler. String doesn't overload the + operator.

Oki. Bad example.
But you get what I mean.

The motto at the moment seems to be something like, "If the compiler
can safely infer some information, the coder shouldn't have to specify
it." I'm starting to really like that...

At first I thought the new 'var' keyword was just sugar for the lazy dude.
But once you get used to inferrence, you feel handicapped without it.

Today, I am going to do some maintanaince in a 1.1 project.
Starting up VS 2003 is no fun! Been avoiding it all morning,
guess I have to get started now. *sob*

- Michael Starberg

 

[Jon Skeet [C# MVP]]

Maybe I should give it another try.
I'll install it later this afternoon. I also liked it alot,
but had to uninstall it because it slowed down Visual Studio to a halt.

Yes, performance tends to be the point people don't like about it. I
would hate to develop without it these days

Yes, all three of them.
Well, whenever someone don't understand co/contra variance with generics,
or threading or whatever, I just redirect them to your website, - Easy!

For covariance/contravariance I usually refer to Rick Byers' blog - I
don't think I've got very much information on that at the moment. Some
time I should add it to the FAQ.

Of course, I'd appreciate it if you'd redirect people to my book after
it's out

Oki. Bad example.
But you get what I mean.
Absolutely.


At first I thought the new 'var' keyword was just sugar for the lazy dude.
But once you get used to inferrence, you feel handicapped without it.

Indeed. I thought I'd be avoiding var like the plague, but I'm now keen
on it - only where it makes sense, of course.

Today, I am going to do some maintanaince in a 1.1 project.
Starting up VS 2003 is no fun! Been avoiding it all morning,
guess I have to get started now. *sob*

Ditto, ironically...