Encapsulation vs Extensibility

Hello everyone,

I see a lot written about how one should strive towards keeping as much
of a class's fields/methods private and only exposing essential
functionality. However, when I first transitioned to OO many moons ago
and started fiddling with inheritence and extending components, I ran
into the 'private' modifier. Each encounter was a pain seeing that it
stopped me from extending the functionality of the class to my liking.
Sometimes I'd be able to work around it, but workarounds in my humble
opinion are just plain ugly, and though I would pat myself on the back
each time I managed the impossible, I couldn't shake the feeling that
something was wrong. While I can see that the 'private' modifier has
its uses, I'm puzzled as to why it's advocated so much given that one
of the strong points of OO is extensibility. I sniff around and there
are other articles written bashing the use of 'private' and how we
should make everything public and live happily ever after.

One camp says this, another camp says that.

There seems to be such a high degree of rigour and the scientific
method being applied in a true scientific field such as physics that it
becomes painfully obvious to me that computer science is nothing more
than a pseudo/cargo-cult science (in honor of one of my true idols in
life, the late Richard Feynman.)

Ernest Rutherford once said ""The only posible conclusion the social
sciences can draw is: some do, some don't." It seems to me that the
same can be said about computer science.

Should I make my fields private? Should I make them public? Should we
bother posing such questions knowing that the answer will be nothing
more than public opinion without any scientific backing?

Excuse my cynicism people... I've been holding this in for the past 20
years. I will be a truly happy camper the day I see some science in
computer science.

Anthony

"Anthony Paul" <anthonypaulo{}> wrote:

> I see a lot written about how one should strive towards keeping as much
> of a class's fields/methods private and only exposing essential
> functionality. However, when I first transitioned to OO many moons ago
> and started fiddling with inheritence and extending components, I ran
> into the 'private' modifier. Each encounter was a pain seeing that it
> stopped me from extending the functionality of the class to my liking.
> Sometimes I'd be able to work around it, but workarounds in my humble
> opinion are just plain ugly, and though I would pat myself on the back
> each time I managed the impossible, I couldn't shake the feeling that
> something was wrong. While I can see that the 'private' modifier has
> its uses, I'm puzzled as to why it's advocated so much given that one
> of the strong points of OO is extensibility. I sniff around and there
> are other articles written bashing the use of 'private' and how we
> should make everything public and live happily ever after.
>
> One camp says this, another camp says that.
>
> There seems to be such a high degree of rigour and the scientific
> method being applied in a true scientific field such as physics that it
> becomes painfully obvious to me that computer science is nothing more
> than a pseudo/cargo-cult science (in honor of one of my true idols in
> life, the late Richard Feynman.)
>
> Ernest Rutherford once said ""The only posible conclusion the social
> sciences can draw is: some do, some don't." It seems to me that the
> same can be said about computer science.
>
> Should I make my fields private? Should I make them public? Should we
> bother posing such questions knowing that the answer will be nothing
> more than public opinion without any scientific backing?
>
> Excuse my cynicism people... I've been holding this in for the past 20
> years. I will be a truly happy camper the day I see some science in
> computer science.

Feeling a little bitter are we? Seriously, I view programming as more of
a craft than a science so I guess I agree with you in the large.

When it comes to public fields I have to say my experiences has been the
opposite of yours. I remember a particular framework where a base class
contained a couple of dozen public fields and I had to know when they
changed in my derived classes. I ended up having to duplicate them all
and then in every method I had to compare the current value of each to
the last known value... A very ugly business.

A couple of thoughts. First, a well written class often has certain
invariants that it must maintain between its fields and it simply cannot
do that effectively if the field is public. Every client becomes
responsible for maintaining the invariant instead of just that one
class. Of course if the class only has one client, then the point is
moot and you might as well make the fields public.

Second, a well written class uses its methods to determine what is going
on in the rest of the system, rather than as commands to act. It sounds
like you are trying to make the objects do things rather than simply
informing them of what is going on. It might not be the fact that the
method/fields are private that is causing the problem, rather it might
be that the classes themselves simply weren't written well.

Can you find people who disagree with my comments above? Of course.
Cabinet makers disagree on which joint is best, because after all, which
is best depends on the context. Programming is much the same, one size
does not fit all. I say, do whatever you think will reduce duplication
and complexity. Sometimes making the field public is just what the
doctor ordered, especially if the class itself never modifies the field,
but simply reads it to determine what is going on in the world.

Every rule has its exceptions (even this one. :-)

Hello Daniel!

I wouldn't call it bitter, rather... disappointed to see that us
programmers seem to be driven by what's fashionable rather than what's
reasonable. I did rant a bit though and for that I apologize, but
sometimes I can't help but wonder if there's anyone else out there that
feels that something's wrong, something's missing, and that we're all
going about this the wrong way.

As for the topic at hand, let's use something that I'm sure a lot of
people will be familiar with, the .NET framework. The WinForms portion
of .NET has a Splitter control that allows you to resize other visual
controls similar to the way in which you can resize a window. The
resizing itself is not dynamic meaning that it does not actually occur
until you let go of the mouse. While resizing via the splitter, it
draws a shadow of itself at your present mouse location that is meant
to represent where it would stay if you were to set it there, do you
follow? So if I were to click on the splitter, hold my mouse down and
move the mouse, the splitter would stay in place but a shadow of it
would appear to move in its place wherever I moved the mouse. Once I
let go of the mouse button, the splitter would move to take the place
of its shadow, the controls would be resized along with it, and the
world is a better place for it.

So I'm playing around with Office 2003 or 2007 and think wow! I love
the interface! Why didn't Microsoft include these nice looking controls
in the .NET toolbox for all of us to play around with? The idea hits
me... I'll make some custom controls in .NET to exactly mimic their
controls! So let's decide on a control... how about the splitter? The
splitter in Office 2003/2007 works differently than the one that's
included in .NET. First of all it's dynamic, meaning that as you resize
the control it does it in real time, you can see it happening as you
move your mouse. Second of all, since it's dynamic it doesn't need to
draw a shadow of itself, so it doesn't.

So the question is : How do I extend the functionality of the
bare-bones .NET splitter control to match that of Office 2003/2007?

It turns out that all of the essential methods/fields necessary in
order to override this behavior are all private, except for the OnPaint
event which only takes care of the aesthetic portion. Everything I
needed was private, which means that I was pretty much screwed. In the
end I had to resort to reflection in order to access these hidden
fields/methods in order to produce the required behavior. Does it
exactly mimic the 2003/2007 style splitter control now? Yes, it does;
but it's ugly, I had to use what is essentially a hack to work around
the problem and the resulting code isn't the thing of beauty and
simplicity that one would expect from OO languages.

So the real question here is, what's wrong with this picture? Maybe I
was wrong to extend it, maybe I should have written it from scratch.
But then, where's the extensibility everyone's talking about? Perhaps
it was Microsoft's fault for not coding it better? But these are really
smart people at Microsoft who've taken all the advanced OO theory
courses and should have known better... what does that tell us in and
of itself? Perhaps the language is to blame? The methodology? The
platform?

*sigh*

Anthony

> So the real question here is, what's wrong with this picture?

Nothing. You insisted on using the .net Splitter control instead of
writing your own. And you hacked yourself a way to accomplish this and
get the behavior you wanted.

> Maybe I was wrong to extend it,

No, but you will have to live with the consequences. When there is a
new version of .net with an updated splitter with different internals,
your code might not work anymore.

> maybe I should have written it from scratch.

Probably.

> But then, where's the extensibility everyone's talking about?

The notion that everything is supposed to be extensible in all possible
ways is absurd.

> Perhaps
> it was Microsoft's fault for not coding it better?

Um, no. Looks like that's how it was designed.

> But these are really smart people at Microsoft who've taken all the advanced OO theory
> courses and should have known better...

Your gripe amounts to a feature request: "allow someone to override
the .net Splitter drag behavior".

"Advanced OO theory"? That's a joke, right?

> what does that tell us in and
> of itself?

It doesn't tell us anything other than you didn't get the feature you
wanted, and you didn't want to build your own Splitter customized to
your own needs.

> Perhaps the language is to blame?

No. "Object-Oriented" doesn't automatically mean something is
extensible.

> The methodology?

No again.

> The platform?

Still no.

You have to forget this insane idea that just because something is
supposedly "OO" that this means it is "extensible". Because it's just
not true.



Anthony Paul wrote:
> Hello Daniel!
>
> I wouldn't call it bitter, rather... disappointed to see that us
> programmers seem to be driven by what's fashionable rather than what's
> reasonable. I did rant a bit though and for that I apologize, but
> sometimes I can't help but wonder if there's anyone else out there that
> feels that something's wrong, something's missing, and that we're all
> going about this the wrong way.
>
> As for the topic at hand, let's use something that I'm sure a lot of
> people will be familiar with, the .NET framework. The WinForms portion
> of .NET has a Splitter control that allows you to resize other visual
> controls similar to the way in which you can resize a window. The
> resizing itself is not dynamic meaning that it does not actually occur
> until you let go of the mouse. While resizing via the splitter, it
> draws a shadow of itself at your present mouse location that is meant
> to represent where it would stay if you were to set it there, do you
> follow? So if I were to click on the splitter, hold my mouse down and
> move the mouse, the splitter would stay in place but a shadow of it
> would appear to move in its place wherever I moved the mouse. Once I
> let go of the mouse button, the splitter would move to take the place
> of its shadow, the controls would be resized along with it, and the
> world is a better place for it.
>
> So I'm playing around with Office 2003 or 2007 and think wow! I love
> the interface! Why didn't Microsoft include these nice looking controls
> in the .NET toolbox for all of us to play around with? The idea hits
> me... I'll make some custom controls in .NET to exactly mimic their
> controls! So let's decide on a control... how about the splitter? The
> splitter in Office 2003/2007 works differently than the one that's
> included in .NET. First of all it's dynamic, meaning that as you resize
> the control it does it in real time, you can see it happening as you
> move your mouse. Second of all, since it's dynamic it doesn't need to
> draw a shadow of itself, so it doesn't.
>
> So the question is : How do I extend the functionality of the
> bare-bones .NET splitter control to match that of Office 2003/2007?
>
> It turns out that all of the essential methods/fields necessary in
> order to override this behavior are all private, except for the OnPaint
> event which only takes care of the aesthetic portion. Everything I
> needed was private, which means that I was pretty much screwed. In the
> end I had to resort to reflection in order to access these hidden
> fields/methods in order to produce the required behavior. Does it
> exactly mimic the 2003/2007 style splitter control now? Yes, it does;
> but it's ugly, I had to use what is essentially a hack to work around
> the problem and the resulting code isn't the thing of beauty and
> simplicity that one would expect from OO languages.
>
> So the real question here is, what's wrong with this picture? Maybe I
> was wrong to extend it, maybe I should have written it from scratch.
> But then, where's the extensibility everyone's talking about? Perhaps
> it was Microsoft's fault for not coding it better? But these are really
> smart people at Microsoft who've taken all the advanced OO theory
> courses and should have known better... what does that tell us in and
> of itself? Perhaps the language is to blame? The methodology? The
> platform?
>
> *sigh*
>
> Anthony

"Anthony Paul" <anthonypaulo{}> wrote:

> I wouldn't call it bitter, rather... disappointed to see that us
> programmers seem to be driven by what's fashionable rather than what's
> reasonable. I did rant a bit though and for that I apologize, but
> sometimes I can't help but wonder if there's anyone else out there that
> feels that something's wrong, something's missing, and that we're all
> going about this the wrong way.

And louis XIV chairs look different than Elizabethan chairs. Like I
said, programming is a craft not a science. It isn't art because we are
constrained by the fact that our product needs to be functional, but
there is a lot of fashion that goes into programing.

> As for the topic at hand, let's use something that I'm sure a lot of
> people will be familiar with, the .NET framework. The WinForms portion
> of .NET has a Splitter control that allows you to resize other visual
> controls similar to the way in which you can resize a window. The
> resizing itself is not dynamic meaning that it does not actually occur
> until you let go of the mouse. While resizing via the splitter, it
> draws a shadow of itself at your present mouse location that is meant
> to represent where it would stay if you were to set it there, do you
> follow? So if I were to click on the splitter, hold my mouse down and
> move the mouse, the splitter would stay in place but a shadow of it
> would appear to move in its place wherever I moved the mouse. Once I
> let go of the mouse button, the splitter would move to take the place
> of its shadow, the controls would be resized along with it, and the
> world is a better place for it.
>
> So I'm playing around with Office 2003 or 2007 and think wow! I love
> the interface! Why didn't Microsoft include these nice looking controls
> in the .NET toolbox for all of us to play around with? The idea hits
> me... I'll make some custom controls in .NET to exactly mimic their
> controls! So let's decide on a control... how about the splitter? The
> splitter in Office 2003/2007 works differently than the one that's
> included in .NET. First of all it's dynamic, meaning that as you resize
> the control it does it in real time, you can see it happening as you
> move your mouse. Second of all, since it's dynamic it doesn't need to
> draw a shadow of itself, so it doesn't.
>
> So the question is : How do I extend the functionality of the
> bare-bones .NET splitter control to match that of Office 2003/2007?
>
> It turns out that all of the essential methods/fields necessary in
> order to override this behavior are all private, except for the OnPaint
> event which only takes care of the aesthetic portion. Everything I
> needed was private, which means that I was pretty much screwed. In the
> end I had to resort to reflection in order to access these hidden
> fields/methods in order to produce the required behavior. Does it
> exactly mimic the 2003/2007 style splitter control now? Yes, it does;
> but it's ugly, I had to use what is essentially a hack to work around
> the problem and the resulting code isn't the thing of beauty and
> simplicity that one would expect from OO languages.
>
> So the real question here is, what's wrong with this picture? Maybe I
> was wrong to extend it, maybe I should have written it from scratch.
> But then, where's the extensibility everyone's talking about? Perhaps
> it was Microsoft's fault for not coding it better? But these are really
> smart people at Microsoft who've taken all the advanced OO theory
> courses and should have known better... what does that tell us in and
> of itself? Perhaps the language is to blame? The methodology? The
> platform?

Perhaps that is a feature they would rather reserve for their own
programs? Whenever you are using a proprietary framework that was
created by a company that produces software of its own, you run the risk
that they will "dumb down" the framework compared to what they use for
their own software. Without knowing the framework (and I don't) I really
can't say.

On 12 Jan 2007 14:06:08 -0800, Anthony Paul wrote:

> I see a lot written about how one should strive towards keeping as much
> of a class's fields/methods private and only exposing essential
> functionality. However, when I first transitioned to OO many moons ago
> and started fiddling with inheritence and extending components, I ran
> into the 'private' modifier. Each encounter was a pain seeing that it
> stopped me from extending the functionality of the class to my liking.
> Sometimes I'd be able to work around it, but workarounds in my humble
> opinion are just plain ugly, and though I would pat myself on the back
> each time I managed the impossible, I couldn't shake the feeling that
> something was wrong. While I can see that the 'private' modifier has
> its uses, I'm puzzled as to why it's advocated so much given that one
> of the strong points of OO is extensibility. I sniff around and there
> are other articles written bashing the use of 'private' and how we
> should make everything public and live happily ever after.
>
> One camp says this, another camp says that.
>
> There seems to be such a high degree of rigour and the scientific
> method being applied in a true scientific field such as physics that it
> becomes painfully obvious to me that computer science is nothing more
> than a pseudo/cargo-cult science (in honor of one of my true idols in
> life, the late Richard Feynman.)

Kind of. (:-))

> Ernest Rutherford once said ""The only posible conclusion the social
> sciences can draw is: some do, some don't." It seems to me that the
> same can be said about computer science.

"All science is either physics or stamp collecting" (:-))

> Should I make my fields private? Should I make them public? Should we
> bother posing such questions knowing that the answer will be nothing
> more than public opinion without any scientific backing?

More or less formal it is a problem such that when developing a type T you
have to decide in which way it will be attuned by the derived type S, of
which you know little if anything. Sorry but no science can give you any
reasonable answer to this. When S is any, then T should be as well. You
cannot tell nothing about neither the visibility attributes of the fields
of T, nor the fields themselves, nor the operations defined on T. It would
be quite unscientific to ask at which temperature water boils. Physicist
would ask in return, what would be the pressure? Then there are some
conditions at which water cannot exist. See the point?

> Excuse my cynicism people... I've been holding this in for the past 20
> years. I will be a truly happy camper the day I see some science in
> computer science.

That would not happen soon. CS is very young. For a science to mature, it
takes 200-300 years, or so.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Responding to Paul...

> I see a lot written about how one should strive towards keeping as much
> of a class's fields/methods private and only exposing essential
> functionality. However, when I first transitioned to OO many moons ago
> and started fiddling with inheritence and extending components, I ran
> into the 'private' modifier. Each encounter was a pain seeing that it
> stopped me from extending the functionality of the class to my liking.
> Sometimes I'd be able to work around it, but workarounds in my humble
> opinion are just plain ugly, and though I would pat myself on the back
> each time I managed the impossible, I couldn't shake the feeling that
> something was wrong. While I can see that the 'private' modifier has
> its uses, I'm puzzled as to why it's advocated so much given that one
> of the strong points of OO is extensibility. I sniff around and there
> are other articles written bashing the use of 'private' and how we
> should make everything public and live happily ever after.

First, let's take a little trip down Memory Lane. Most of the
public/private debate is rooted in the fact that the early OOPLs painted
themselves into a corner by allowing direct access to knowledge
attributes in the syntax (e.g., <obj ref>.<attr name>). At the 3GL
level a knowledge responsibility /must/ be mapped directly into a memory
storage type. So that created physical coupling between the accessor
and the owner because the compiler could not produce correct code in the
accessor without knowing the memory storage type. So when the
implementation (i.e., the memory storage type) was changed, one had to
at least recompile the accessor.

The workaround was to hide the knowledge attribute implementation by
making it private so it couldn't be accessed externally and then
providing public getters/setters for the attribute that could
encapsulate changes to the implementation so that they were transparent
to the accessor.

There was an analogous problem in accessing behaviors, albeit much more
rare. One might create a behavior that was invoked by other object
behaviors. One did this to manage complexity of the implementation so
that the code was more maintainable. However, in rare situations
invoking that behavior by itself without the context of the other object
behavior could lead to data integrity problems for the knowledge
attributes that it set. So, once again, the workaround was to make such
support methods private so that they couldn't be accessed.

In both cases the key notion is implementation hiding. More relevant,
implementation hiding only became an issue because of the way the 3GL
OOPLs used types or because of a very rare situation involving method
decomposition to make the code more readable. IOW, public/private
really has nothing much to do with the solving the customer's problem;
it is a kludge to deal with peripheral type system and maintainability
problems _at the 3GL level_.

[There is yet another justification of public/private based on
information hiding. The original developer uses public/private to hide
properties because that developer doesn't think other objects have a
need to know. That's valid but it has a problem in that it requires
prescience on the part of the developer to know that the properties will
not be needed externally when the requirements change. It is also a
binary decision that can't be tailored to context. In practice there
are more powerful tools in modern OOPLs, like providing multiple
interfaces, that allow one to control access on a case-by-case basis.
So I don't see that argument as decisive.]

There is also an implicit context in the use of public/private. One
uses private to /prevent/ developers from making a mistake by accessing
certain properties when encoding other objects at a later time. There
are two implicit assumptions in that context: (A) the documentation of
the property is insufficient to identify the potential access problem
and/or (B) the developer is incompetent. Either way I think one has
more systemic problems that aren't going to be fixed by applying a
priori bandaids about public/private.

So put me in the camp that doesn't worry a whole lot about
public/private. B-) At the 3GL level I always used getters/setters for
knowledge attributes; I used other mechanisms for limiting access; and I
only made methods private that I /knew/ would cause data integrity
problems if invoked standalone. [Now, as a translationist, I don't
worry about it at all. B-)) Public/private qualifiers are not even in
the UML profile that translationists use for application development so
I couldn't use them if I wanted to do so.]

Second, insofar as the metaphysical and epistemological issues are
concerned, I agree that what we do is not a science. But I do think
that it is engineering. All engineering practitioners apply a mixture
of rote methodological process and intellectual creativity. Engineering
methodologies are based on science and when science advances the
engineering methodologies are adjusted as those science advances are
disseminated.

The problem with software development is that it is very young compared
to other engineering fields. As a result, there is relatively little
/proven/ science available as a base compared to other engineering
fields and the learning curve is steep as new hypotheses replace old
ones. So the field is still rapidly evolving as the science is
provided. (I think the history or public/private is a good example of
that.) Thus most software shops are stuck with going to war with bows
and arrows (e.g., 3GL coding) because the science of gunpowder (e.g.,
4GLs) only recently matured (ca late '90s) and hasn't been disseminated yet.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Anthony Paul wrote:

> I see a lot written about how one should strive towards keeping as much
> of a class's fields/methods private and only exposing essential
> functionality. However, when I first transitioned to OO many moons ago
> and started fiddling with inheritence and extending components, I ran
> into the 'private' modifier. Each encounter was a pain seeing that it
> stopped me from extending the functionality of the class to my liking.

It is indeed so in a prog lang that has inferior access control to
type properties.


> Sometimes I'd be able to work around it, but workarounds in my humble
> opinion are just plain ugly

Often the case in a prog lang that has inferior access control to
type properties.


> and though I would pat myself on the back
> each time I managed the impossible, I couldn't shake the feeling that
> something was wrong. While I can see that the 'private' modifier has
> its uses, I'm puzzled as to why it's advocated so much given that one
> of the strong points of OO is extensibility.

A strong feature of OO is extensibility.
But who is 'advocating' the use of private 'so much' ??


> I sniff around and there
> are other articles written bashing the use of 'private' and how we
> should make everything public and live happily ever after.

> One camp says this, another camp says that.

I believe this is an example of a concept known as *opinion* .


> There seems to be such a high degree of rigour and the scientific
> method being applied in a true scientific field such as physics that it
> becomes painfully obvious to me that computer science is nothing more
> than a pseudo/cargo-cult science (in honor of one of my true idols in
> life, the late Richard Feynman.)

And the use of the 'private' construct in OO relates to the rigour of CS
how exactly ??


> Ernest Rutherford once said ""The only posible conclusion the social
> sciences can draw is: some do, some don't." It seems to me that the
> same can be said about computer science.

How very true.
The Halting problem : will my program halt ??
Nah, all Turing et al could say was : some do, some don't.


> Should I make my fields private? Should I make them public? Should we
> bother posing such questions knowing that the answer will be nothing
> more than public opinion without any scientific backing?

What is the 'scientific backing' that determines whether properties of a
type should be made public or private ??


> Excuse my cynicism people... I've been holding this in for the past 20
> years. I will be a truly happy camper the day I see some science in
> computer science.

You'll be a happy camper when you've overcome your ignorance of how
access control is implemented in less than inferior prog langs.
Probably couuple with not using prog langs having inferior access control
schemes.


Regards,
Steven Perryman

Anthony Paul wrote:
> Hello Daniel!
>
> I wouldn't call it bitter, rather... disappointed to see that us
> programmers seem to be driven by what's fashionable rather than what's
> reasonable. I did rant a bit though and for that I apologize, but
> sometimes I can't help but wonder if there's anyone else out there that
> feels that something's wrong, something's missing, and that we're all
> going about this the wrong way.
>
> As for the topic at hand, let's use something that I'm sure a lot of
> people will be familiar with, the .NET framework. The WinForms portion
> of .NET has a Splitter control that allows you to resize other visual
> controls similar to the way in which you can resize a window. The
> resizing itself is not dynamic meaning that it does not actually occur
> until you let go of the mouse. While resizing via the splitter, it
> draws a shadow of itself at your present mouse location that is meant
> to represent where it would stay if you were to set it there, do you
> follow? So if I were to click on the splitter, hold my mouse down and
> move the mouse, the splitter would stay in place but a shadow of it
> would appear to move in its place wherever I moved the mouse. Once I
> let go of the mouse button, the splitter would move to take the place
> of its shadow, the controls would be resized along with it, and the
> world is a better place for it.
>
> So I'm playing around with Office 2003 or 2007 and think wow! I love
> the interface! Why didn't Microsoft include these nice looking controls
> in the .NET toolbox for all of us to play around with? The idea hits
> me... I'll make some custom controls in .NET to exactly mimic their
> controls! So let's decide on a control... how about the splitter? The
> splitter in Office 2003/2007 works differently than the one that's
> included in .NET. First of all it's dynamic, meaning that as you resize
> the control it does it in real time, you can see it happening as you
> move your mouse. Second of all, since it's dynamic it doesn't need to
> draw a shadow of itself, so it doesn't.
>
> So the question is : How do I extend the functionality of the
> bare-bones .NET splitter control to match that of Office 2003/2007?
>
> It turns out that all of the essential methods/fields necessary in
> order to override this behavior are all private, except for the OnPaint
> event which only takes care of the aesthetic portion. Everything I
> needed was private, which means that I was pretty much screwed. In the
> end I had to resort to reflection in order to access these hidden
> fields/methods in order to produce the required behavior. Does it
> exactly mimic the 2003/2007 style splitter control now? Yes, it does;
> but it's ugly, I had to use what is essentially a hack to work around
> the problem and the resulting code isn't the thing of beauty and
> simplicity that one would expect from OO languages.
>
> So the real question here is, what's wrong with this picture? Maybe I
> was wrong to extend it, maybe I should have written it from scratch.
> But then, where's the extensibility everyone's talking about? Perhaps
> it was Microsoft's fault for not coding it better? But these are really
> smart people at Microsoft who've taken all the advanced OO theory
> courses and should have known better... what does that tell us in and
> of itself? Perhaps the language is to blame? The methodology? The
> platform?

This is interesting, but sort of recurring phenomenon.
The thing is that the designer of the class must have the exact idea
about the usage of its class - each use case should be known. This
amounts to requirements and scope.

Given these requirements it is more or less straightforward to provide
an interface to support these requirements. Everything else is an
implementation detail and should be hidden from the users (i.e. private).
Producing a class is no different than producing anything else (material
or virtual) - you think about what you want (or have some specific
requirements on your hands), devise an interface for your users, and
implement it.

The MS folks obviously didn't have this usage in mind for the .NET
splitter. Maybe they didn't want to support it, or maybe they didn't
think of it. Admittedly - it's not easy task when you have world wide
programmers as clients of your class. I don't suppose I would have done
it better myself :-)

So my answer to you would be - it's simply the way it is. It's
impossible to anticipate all the needs of all clients. You create some
boundaries, i.e. you define the scope - what will you fulfill, and
implement it.

Sasa

Anthony Paul wrote:
> Hello everyone,
>
> I see a lot written about how one should strive towards keeping as much
> of a class's fields/methods private and only exposing essential
> functionality. However, when I first transitioned to OO many moons ago
> and started fiddling with inheritence and extending components, I ran
> into the 'private' modifier. Each encounter was a pain seeing that it
> stopped me from extending the functionality of the class to my liking.
> Sometimes I'd be able to work around it, but workarounds in my humble
> opinion are just plain ugly, and though I would pat myself on the back
> each time I managed the impossible, I couldn't shake the feeling that
> something was wrong. While I can see that the 'private' modifier has
> its uses, I'm puzzled as to why it's advocated so much given that one
> of the strong points of OO is extensibility. I sniff around and there
> are other articles written bashing the use of 'private' and how we
> should make everything public and live happily ever after.

Your cynicism is truly joyous, accurate and incisive.

Three years ago I had a similar crisis with OO....everything was
opinion, magic, smoke and mirrors....to a degree it still is but I
understand enought to know that;

i) some opinion is plain wrong
ii) some opinion is correct but dependent on the problem in hand
iii) and some is always utterly true, hard fact.

The private/public/protected thing is largely the second (but sometimes
blurs into the other two).

>
> One camp says this, another camp says that.
>

largely because one set is talking about getting stuff out the door
that works.
another is talking about getting it out of the door cheaply.
another is talking about getting it out of the door so that when we
change it it will still work.
another is talking about getting it out of the door so that when we
change, we don't have to rewrite it from the ground up.
etc
etc

Most of these decision are largely instinctive, I used to like code
that was easy to extend, but got irritated with it taking ages to
design code that I never extended....there are still occasions when I
know something needs to be flexible...but it costs time, effort,
complexity, and more bugs.....I errr to private now more than I used
to.

> There seems to be such a high degree of rigour and the scientific
> method being applied in a true scientific field such as physics that it
> becomes painfully obvious to me that computer science is nothing more
> than a pseudo/cargo-cult science (in honor of one of my true idols in
> life, the late Richard Feynman.)

True.......it's more like engineering.

>
> Ernest Rutherford once said ""The only posible conclusion the social
> sciences can draw is: some do, some don't." It seems to me that the
> same can be said about computer science.

There is science in computing, but you don't find much in OO
books....or here.

>
> Should I make my fields private? Should I make them public? Should we
> bother posing such questions knowing that the answer will be nothing
> more than public opinion without any scientific backing?

It cannot have simple scientific backing.....are integers better than
rationals?.....there is no mathematical answer.....you can argue the
pro's..the integers are easier to construct......but the rationals are
easier to describe (in some sense they are better behaved)....we can
construct the rationals from the integers, so the integers are
best....but we can consider the integers as a subset (! space) of the
rationals...so they're better......whats the answer?

you're expecting hard answers to soft questions.

is private better than protected.....it depends...if I want to
extend...then protected....if I want simplicity then private...they are
competing demands.

>
> Excuse my cynicism people... I've been holding this in for the past 20
> years. I will be a truly happy camper the day I see some science in
> computer science.
>
> Anthony

Your cynicism is refreshing.....at least you're not claiming to have
the answers....