Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why do you make class members private?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 117 posts

Re: Ask HN: Why do you make class members private?

#41

Post by frenchy »

jstx1 wrote: post #17
actusual wrote: post #12

Earlier quoted context omitted.

Python would like a word...

While we're on Python and private methods - what's with everyone just _underscoring every method and variable by default? Does anyone teach people to do this or have I just ran into a few people with this habit by chance? I know what _underscoring does in Python and what PEP8 recommends but doing it all the time for everything is so ugly and unnecessary.

Probably for the same reason that zero-based versioning (https://0ver.org/) is so popular. People want to avoid commitment.

Re: Ask HN: Why do you make class members private?

#43

Post by jacquesm »

klyrs wrote: post #34

> You have been taught to do it so you just do it without thinking. Ouch, that's a pretty careless reason to start with. Why does insulting your audience seem like the right first move? In much of the classist (classy? You decide) code I've written, the entire reason that I've chosen to encapsulate the data into a class is that maintaining a consistent data structure requires book-keeping. The fields and methods asso…

> A dedicated user can gain access to, and modify, everything.

That may be so, but it is akin to using an undocumented system call. And good luck if that class ever gets refactored or turned into a service.

Re: Ask HN: Why do you make class members private?

#44

Post by CoolGuySteve »

jacquesm wrote: post #13

To hide implementation details from class users. You ideally only want to have a documented interface and all implementation details should be opaque to class users. This can be quite tricky and usually classes will export some state, typically done through getters and setters. Then one day you decide you want to aggressively refactor that class. Now you can because the interface can stay the same even though you cou…

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs and private implementations has failed?

Admittedly, my opinion is mainly based around working mostly in C++, but every codebase I work in of significant age is a knitted castle of interlocking classes with poorly thought out accessors and private variables. While the vision of carefully encapsulating implementation details is nice, in practice the discipline required to do so seems unachievable.

Instead of using private members, if I want an interface I explicitly make an abstract base class interface and inherit from it.

This has two advantages: (1) unit tests are simpler when I can poke/prod the concrete internals because they're public. (2) I can make an "include" directory with the interfaces in it when I want to distribute a shared library and those interfaces will be more concise and less likely to leak all sorts of implementation details in the headers.

Re: Ask HN: Why do you make class members private?

#45

Post by Jtsummers »

ironmagma wrote: post #15

We do it because that's how it's always been done. There is no why of OOP, there is only do.

> There is no why of OOP, there is only do.

You really think that in the 50+ years of OOP and modular programming no one has considered why? That they've really just thrown shit at the wall and seen what stuck and never considered what to throw at the wall or why it stuck?

Re: Ask HN: Why do you make class members private?

#46

Post by vanjajaja1 »

robalni wrote: post #31
xdavidliu wrote: post #7

https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...

That's what it's called when you do things like that but what's the reason? From the linked page I read: "Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods." So there are two possible reasons here: 1. The access could "ex…

Consider a class like a HashedLinkedList. This is a linked list which allows direct access to nodes using dictionary look up. It is generally implemented with a LinkedList and Dictionary internally. The expectation is that all elements in the dictionary are in the linked list. Any deviation from this implementation detail will cause invalid state.

Making the list or the dictionary public opens you up to situations where consumers of the code modify either datastore independently and corrupt the consistency of the class.

Re: Ask HN: Why do you make class members private?

#47

Post by [deleted] »

klyrs wrote: post #34

> You have been taught to do it so you just do it without thinking. Ouch, that's a pretty careless reason to start with. Why does insulting your audience seem like the right first move? In much of the classist (classy? You decide) code I've written, the entire reason that I've chosen to encapsulate the data into a class is that maintaining a consistent data structure requires book-keeping. The fields and methods asso…

[deleted]

Re: Ask HN: Why do you make class members private?

#49

Post by Centigonal »

I see a class as the implementation of an interface. The "interface" part of the class should be public, while the "implementation" part of the class should be private. That way, if you ever have to refactor or change the class, you can be confident your colleagues haven't built stuff on top of the "implementation" part of the class, and that you can change whatever as long as you maintain the same interface.

Re: Ask HN: Why do you make class members private?

#50

Post by moffkalast »

blacksoil wrote: post #48

-To hide implementation details from users of the library. We don't want to unnecessarily expose functions -Reduce the amount tests, as the private functions wouldn't have to be explicitly tested

It probably also lets the compiler do more optimizations than it otherwise would've, but that's just a guess and largely compiler dependent.

Outside of library usage though? Mostly counterproductive in my experience.

Post reply on HN