Why the "private" keyword is the modern day "goto"

Why the "private" keyword is the modern day "goto"(davidarno.org)

19 points by steamboiler 15 years ago | 23 comments

btn 15 years ago |

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 15 years ago |

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 15 years ago |

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 15 years ago |

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 15 years ago |

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 15 years ago | |

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.

barrkel 15 years ago | |

It's precisely because you can't predict everything that people will do with your library that you limit its extensibility to only those situations you've designed for. That way, when you come out with the next version, you have a much higher expectation that you won't be breaking users' code, and those users will be far less upset at you.

It's not about treating everyone like idiots. It's about responsibly designing for and managing change over time.

And thus you should almost always make fields private, make methods non-virtual, make classes final / sealed, etc., except in those situations where you've carefully considered the ramifications and designed for them.

extension 15 years ago |

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 15 years ago |

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 15 years ago | |

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 15 years ago |

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

brown9-2 15 years ago |

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 15 years ago |

Shocked he did not use this title:

"Private" Keyword Considered Harmful

Lispy_Lisp 15 years ago |

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

stan_rogers 15 years ago | |

"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 15 years ago |

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 15 years ago |

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

HyprMusic 15 years ago |

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 15 years ago | |

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 15 years ago |

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 15 years ago |

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 15 years ago |

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 15 years ago |

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