Ask HN: Why do you make class members private? • Hacker News Board

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

#51

Post by 300bps » Mon, Jul 25, 2022, 6:40 PM UTC

CoolGuySteve wrote: post #44

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…

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs has failed? [...] mainly based around working mostly in C++

Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.

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

#52

Post by tejohnso » Mon, Jul 25, 2022, 6:40 PM UTC

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…

> you could completely re-do the guts...all your tests will still work

That's optimistic. I suspect there are some people who would be confused by your statement if they've been exposed mostly to tests that verify the steps taken by the implementation.

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

#53

Post by jacquesm » Mon, Jul 25, 2022, 6:40 PM UTC

tejohnso wrote: post #52

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…

> you could completely re-do the guts...all your tests will still work That's optimistic. I suspect there are some people who would be confused by your statement if they've been exposed mostly to tests that verify the steps taken by the implementation.

That's what I would call 'brittle tests'.

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

#54

Post by booleandilemma » Mon, Jul 25, 2022, 6:41 PM UTC

This reads more like a question for Stack Overflow or https://softwareengineering.stackexchange.com/ than HN, to be honest.

You sound like a junior developer looking for guidance.

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

#55

Post by highspeedbus » Mon, Jul 25, 2022, 6:42 PM UTC

To keep narrow waists between your software layers.

A low surface area API means clean, elegant code that is simpler to use and understand.

>To clarify, I'm only talking about code in the same project that everyone has access to. I'm not talking about defining an API for other people to use that don't have access to the code, like when you make a library.

The concept of API still applies to same codebase modules. Ditching it is the shortest path to spaghetti code.

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

#56

Post by jacquesm » Mon, Jul 25, 2022, 6:42 PM UTC

CoolGuySteve wrote: post #44

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…

No.

I think that compared to the giant hairballs of absolutely unmanageable spaghetti classes when done right have made larger scale projects tractable to mere mortals and have significantly improved software maintenance.

Classes done wrong (hundreds or even thousands of classes that all do almost nothing) are a terrible anti-pattern and should be avoided.

The exact same thing goes for services. And in fact for any tool used in a really bad way.

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

#57

Post by fny » Mon, Jul 25, 2022, 6:43 PM UTC

> I'm not talking about defining an API for other people to use that don't have access to the code, like when you make a library.

It's for the same reasons. When you write code you are always writing code that some other human will consume through an interface of sorts. Even on small three person projects two truths hold:

- Your project mates are other humans.

- Your future self is an other human.

By defining members as private you're announcing in code to other humans that the private members are important only to the internal implementation of the class and should not be used elsewhere. And yes, your future self with thank you for the distinction.

Now, you don't need to have private methods. In some languages, a work around is to label the methods as "private" by adding a prefix of some sort like an underscore.

Another more functional reason has to do with inheritance. Private methods have different behaviors in different languages when inherited.

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

#58

Post by anamax » Mon, Jul 25, 2022, 6:45 PM UTC

I minimize the externally visible names even/especially when I'm the only programmer on the project.

I do that so that "future me" has as little to understand as possible. ("reduce the number of files to search" seems silly in a world with filename wildcards and find. Are "modern" tools less capable?)

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

#59

Post by CoolGuySteve » Mon, Jul 25, 2022, 6:48 PM UTC

300bps wrote: post #51

CoolGuySteve wrote: post #44

Earlier quoted context omitted.

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…

Can we acknowledge yet that the concept of classes as tiny programs with tiny APIs has failed? [...] mainly based around working mostly in C++ Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.

It's been a decade since I used C# but the corporate design pattern culture of that language back then turned me off of it forever.

Everything looked like this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Maybe it's better now but the Java/C# practice of shoveling largely empty classes around with an IDE isn't something I'd point to as a good example.

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

#60

Post by thefz » Mon, Jul 25, 2022, 6:51 PM UTC

Encapsulation is a founding principle of OOP. You should not be able to directly tool with a class' internals, but use its methods to interact with it.

The practical reason is that this way you have limited paths (methods) with which the inner workings of a class can be modified with, whereas if anything would be public, any other obejct would be able to change a class' status rendering debugging incredibly more complicaed.

This is also a part of the Open-Closed principle: "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle