Smalltalk public methods vs private/protected methods [closed]

Question

I noticed that the Smalltalk language has no concept of private/protected methods. All methods are public. Coming from a Java/C++ background, I've thought of this as a fundamental weakness in the language as any application created in Smalltalk would be completely open to manipulation. I guess you could rely on naming conventions to document the public API and prefix methods to indicate them as private (I believe Squeak does this), but it's still completely open.

Are there any benefits to this approach over having explicit access modifiers to control access to method invocations?

Negligence

Answer 1

Indeed, the Smalltalk way is to put private methods in the 'private' category. This indicates that you shouldn't use these methods, but of course doesn't enforce this.

This is by design - it's a feature, not a bug. Smalltalk was designed from the beginning precisely to be an open system.

Some advantages:

• If I simply have to - maybe the library designer didn't foresee a need to expose some particular thing I simply have to have - I can still call those private methods. Obviously, this isn't something one does lightly: rather, judiciously, cautiously, knowing that it's a tactical solution.
• Language simplicity.
• (As per Alexandre Jasmin's comment) Smalltalk makes no distinction between what you, the programmer, can do and what the language/environment can do. That means that Smalltalk-the-image exposes all the things needed for you to build your own inspectors/debuggers/whatever without having to supply special tools using we-can-do-this-but-you-can't techniques.

Surplus

Another advantage is live inspecting/manipulating/debugging the state of the system. Even private instance variable are accessible using #instVarNamed: if the need arises. – Javed

Indeed; #storeString will often produce something that uses #instVarAt:put:, another one of those dangerous tools. – Surplus

@Frank, I'm not against the approach taken, it's just a little weird. Typically, when I develop reusable components, I want other developers to think of them as black boxes that should not be altered. They can simply concentrate on what they need to do, and adapt the code if they need to. It's the concept of 'classes should be open to extension, but closed to modification' that is at the back of my head when I look at this. – Negligence

Keep in mind Smalltalk is an old language. At its "invention" no one thought about visibility. Design considerations where completely different than for Java or C++. – Coth

David Parnas, 1970, On the Criteria to Be Used in Decomposing Systems Into Modules. C, 1969-1973, controlling visibility by not exposing functions in the header file. – Surplus

@DesolatePlanet the Smalltalk approach is a compromise that allows users to treat your component as a black box in common cases, but still gives them the freedom to do whatever they may need to do in situations you don't cover/foresee (which seem to always come up, at least for me). In Smalltalk, many things that constrain users in other languages rely on trust. It's one of the reasons I use Smalltalk - I know I have the freedom to mold the system in any way I need, not just limited to those baked in. – Footstone

@Sean I don't think it's a compromise so much as axiomatic to the ideal that Smalltalk implements: an open system. – Surplus

@FrankShearar indeed, it's definitely an important part of the Smalltalk value system. I was speaking to DesolatePlanet's concern about the 'black box'-ness of St components, and I think St's approach strikes a great practical balance between protection and power. – Footstone

@DesolatePlanet As I understand the purpose of the open-closed principle, the closed part means you shouldn't have to edit the source code to add new functionality. I don't think it's helpful here. – Footstone

Answer 2

Private and protected methods are in fact a significant weakness of languages like c++, java and c#. They basically say to their users: I don't want to learn and evolve. The consequence of that (and a lot more early binding) is that those languages require much more BDUF and are thus far less usable for a modern (agile) development process.

Staal

It's not ideomatic in those languages. You can, but then can use no libraries written by others – Staal

I guess you have no idea what you are talking about. What has the fact tha my own methods may use default access have to do with other libraries? Private and protected methods are for hiding internal state. – Coth

State is defined by attributes, your methods should be public, and if you feel they should be private then you should probably create a different class. Object Oriented theory does not support private methods, such just a concept which I think was introduced by languages and it's one of the main sources of bad practices, unmantainable and untestable code. – Legroom

@Angel, as I've seen when switching to Smalltalk after 10 years of Java and Delphi, private and protected methods kill evolvability and reusability. You might want to try it and learn real OO. fd8s0 +1 – Staal

Methods can be used in many ways. Providing services as a part of the object's interface is most prominent. But method can be also part of the lowest-level decompositon. Extract private method is a very useful refactoring when you want to name some part of other method - to make it more readable. However, if this private method starts being used, it actually kills evolvability in this case. Private is useful concept even on method level. Maybe this usage for private method is caused by complex enterprise code combined with lower expressivity of languages like Java, but it has its usages. – Leatherback

@Legroom Upvoted, very interesting point! Could you back up your statement that "oo theory doesn't support private methods" with some links/references? Thank you. – Tympan

I'm not good with books, but since the book they used in college was just someone (this is not like algebra theory), I'm with Stephan, it probably all comes from Smalltalk, the language didn't enforce accessibility as far as I remember, the main goal of object oriented was to have small objects which had their own responsibilities, if you start chaining private methods that usually becomes really complex and it serves no purpose since other objects can't "talk" to your object through that, I personally can't read private methods, when I see one I flag the code as garbage / needs re-thinking – Legroom

further more, if you can't call the method from outside your class then you can't re-use that code, if you think your code in that way then you are writing code that is not re-usable on purpose, that's just a shame, with a little effort you can save yourself a lot of time in the future – Legroom

Answer 3

The first question is what private/protected access modifiers are about? Fundamentally, it is not about safety or security. It is about exposing the right interface to the user. Starting from that, it makes little difference between having categories protected/private and a language construct specifically for that.

I would even say that having private/protected visibility modifier brings more complexity to the problem than it actually solves.

Besides that, I don't think that private/protected visibility is a good answer to this problem

Scoundrelly

Answer 4

At the least, Smalltalk should have the textual convention that method names that begin with 'underscore' are verboten to call outside of the objects themselves. Unfortunately, I don't think that 'underscore' is allowed as the first character of a method name.

Clomb

Underscores are permitted in selectors in SOME Smalltalk dialects. Historically speaking, the underscore was used as a stand-in for a left-pointing arrow (the assignment operator). – Surplus

using private category accomplishes this in more natural smalltalk way. – Selfcontent

I'd refer to the accepted answer as to why this is not a good idea. It encourages bad code. There's some sector of the dev population that seems very much against the idea of having a lot of classes, but that's exactly what OOP is all about, have a lot of small classes that you can re-use. – Legroom