

Why the "private" keyword is the modern day "goto" - steamboiler
http://www.davidarno.org/2010/07/22/why-the-private-keyword-is-the-modern-day-goto/

======
btn
The author seems to misunderstand the open-closed principle, and his first
example confuses bug-fixing with API modification. The open-closed principle
is designed to promote API stability and reduce errors caused by API contract
changes that cascade to its users. A class should expose an interface that
allows for such contract changes to be encapsulated in subclasses. This is not
a "debunked" or "outdated" idea, especially if you are designing APIs for
public consumption.

Then there's a bunch of stuff about properties that seems to go around in a
circle...

It seems that his rationale for this rant stems from poor API design by others
---where class modification through sub-classing is impossible to achieve
because of opaque interfaces. This has nothing to do with people using private
variables, and all to do with people not designing proper and extensible
interfaces.

------
edanm
I found a few problems with the article.

Firstly, right at the end, he says: "Remember, unless you unlucky enough to be
using Java or another archaic language with no proper property support, you
can always refactor your class to replace a public field with a protected one
with a public accessor property if requirements change". Is Java really
considered archaic nowadays? C++ and Java probably make up a fairly large
portion of programs written today, and this article doesn't address them.
Probably should have mentioned that at the top of the article.

Secondly, his example of why the principle of “open for extension but closed
for modification” is a not great. He gives an example of a class with a "div"
method that is found to contain a bug. Instead of fixing the bug, a "div2"
method is added which fixes that bug.

The problem is, that's exactly the approach I would advocate in plenty of
situations. When I was in charge of QA for an embedded system, if he'd have
come to me with a bug 1 week before a release, I would never have agreed to
fix it. In a big enough system, you can never tell what code relies on bugs to
work, and would break if that bug was removed. This is a lesson that was hard
to teach most of the programmers, but in the end, whether the system actually
works or not matters a lot more than whether the code contains any bugs.

------
dpapathanasiou
OO seems to be the proverbial elephant: everyone touches a different aspect of
it, and comes away with a different understanding.

Unlike the blog author, I'm not sure the most important part of it is data
hiding.

Alan Kay said in 2003: " _OOP to me means only messaging, local retention and
protection and hiding of state-process, and extreme late binding of all
things._ "

In terms of the last part of that definition (the late binding aspect), I saw
Kay give a demo where he described a framework wherein any method can act on
any object.

I.e., he rejected the C++ style idea that a method is bound to a specific
class, and can only act on that class.

This is an idea from Smalltalk, and you can also do it easily in Lisp.

BTW, if this seems unnatural, think about the Visitor pattern, which allows
you to do exactly this, within the framework of C++ style class definitions.

------
limmeau
There _is_ a difference between a library author thinking his users are too
stupid and a library author reserving the right to replace his tree-map-with-
cached-most-recently-accessed-element with a hashmap in the next version.

------
jameskilton
The article may be a bit on the drastic side, but I do agree with the
conclusion that libraries should not treat everyone like idiots. Keep the
users from shooting themselves in the foot, yes, but If someone is extending a
class in a library, then they have the burden of doing it right. No developer
can predict everything people will want to do with his/her library.

~~~
edderly
But that doesn't directly address compatibility. Most people will expect some
level of compatibility if the library was revised and having the guts of your
interface hanging out isn't going to help.

------
extension
_Imagine I have a system that generates a series of graphs based on a changing
complex number. I could use a round-robin approach of constantly calling a set
of functions, passing in a new complex number each time. This would work, but
it’s incredibly clunky and doesn’t scale well. Alternatively, I could create a
sub-class of ComplexNumber that uses a callback to expose its fields to just
the main controlling class. I then use dependency injection to give all the
graph drawers access to a reference to that value. The graph drawers can then
run independently (say in different threads) and only the controlling class
gets to change the value contained by that reference. This is a far neater.
more robust and more scalable solution._

So, the neat, robust, scalable solution is to subclass his immutable value
class to make it mutable and then inject it into code expecting the immutable
class and change it behind their backs?

Step away from the compiler...

------
cturner
I'd go further. I think inheritance is the modern day goto. I used to consider
myself a bit of a 'framework engineer'. I was wrong. Inheritance creates
structures that are difficult for you to refactor and others to understand.

As I moved away from java and settled into the vibe with python, I've
abandoned inheritance. I use simple objects, but tend to orient encapsulation
around modules, at to do real encapsulation at this higher level (rather than
with classes). It's faster to write, easier to read and much easier to
refactor.

I like the Kay quotes that dpapathanasiou raises in another comment here. Are
there books or other references that seek to teach "message-oriented
programming" with mainstream languages like C or Java?

(On the author's main point I disagree. If you're going to do a lot of
inheritance you need private variables, otherwise it's easy for descendants to
create hard-to-diagnose bugs.)

~~~
limmeau
The interface between a superclass and its subclasses is just another
interface (or rather say, a pair of interfaces: sub-calls-super and super-
calls-sub). However, many if not most superclass-subclass interfaces are not
designed and documented like proper interfaces.

------
Lendal
Using private where you should should use protected is nowhere near as bad as
using goto.

------
brown9-2
Title is a bit incendiary, what the author really means is this:

 _Before we go any further, let me make one thing clear: the well thought out
use of public properties and hidden fields is good practice as it hides the
implementation. What I’m suggesting is that blindly using them in a simple
full-mutable record-style (or tuple-style if you prefer) class is bad
practice._

------
smackfu
Shocked he did not use this title:

"Private" Keyword Considered Harmful

------
Lispy_Lisp
TFA lost me at "object-orientated" and the examples in Visual Basic.

~~~
stan_rogers
"Oriented" versus "orientated" is a which-side-of-the-pond issue. Most Brits
are naturally inclined to use "orientated" where Americans would use
"oriented" (which, to them, would mean something along the lines of "lustrous"
or "pearlescent" but with an archaic flavour). Some are able to swallow the
bile and use a word that feels just _wrong_ when writing for an international
audience, but not all.

------
mark_l_watson
I agree, at least partially, with the author.

In Java, I use package visibility a lot and since starting to use Ruby in a
big way about 5 years ago, I often just make attributes public - no
getters/setters. A bit sloppy, but makes code shorter and easier to read. I
admit that this makes APIs less stable, etc.

On large or huge projects, I would follow conventional wisdom for Java best
practices, but for smaller projects, shorter code and better readability works
for me.

------
Uchikoma
He uses the word "refactoring" exactly the wrong way.

------
HyprMusic
I couldn't agree more. As someone who deals with implementing and customising
3rd party libraries a lot, it's highly frustrating when things are private
just for the sake of it. Things should be made private when there's a specific
way of accessing/altering that variable, not because you don't think anyone
will need it.

~~~
phaylon
Not sure I agree. As soon as something is public, it's part of the interface.
That means the usual rules of stability/back-compatibility will apply to it as
well. If you don't want that, or you're not sure you want that, then that's a
valid reason to make something private in my opinion.

------
seamlessvision
The author clearly has no concept of using the best tool for the job, he just
has a beef with a few programmers doing things wrong, and his response is to
act just like them.

I'm sure he was the kid on the playground who took his ball and left if
someone didn't play by his demanding rules.

------
kelnos
He completely lost me here:

"The 'goto' statement took a long time to die, but it has gone from being a
fundamental programming concept to a programming pariah used by only the most
misguided of developers."

Rather ignorant, and just plain incorrect.

------
bmm6o
The divide by zero anecdote is really odd. He offers it as an example of
something crazy "they" used to do in the olden days (before "they" knew
better), but the twist at the end is that he proposed it and his coworkers
voted it down.

------
wallflower
"In C++, friends can touch each other's private parts"

