It shows that you stopped reading at that point. His point was not that public attributes are just as good or better than getters and setters, his point was that the internals of a class should be as restricted as possible and having getters and setters violates that.
If you actually read the article, you would see this:
```My "default" is to start with a private final member, set only by the constructor. No getter or setter!
If another class absolutely needs to see this member, I think about why. I try to see if there is a behavior that I can expose instead, and create a method for that behavior.```
My points wasn't on good/bad. He said that both ways give you the same result. And this is wrong. That was what I wrote about.
Second, but not least. Getters and setters can also be restricted, if you need that.
Third, there could be dozens of parameteres. Constructor will become huge and I personally don't like that. For that I'd better use a factory, that will garantee to create a valid object. For any other call there's code review to deny them.
Fourth, there's metaprograming in many languages. That lets you use even private members. So I don't see a reason to be so paranoic about that. But private members could give you headache when writing unit tests or changing class with tens of references to that private member.
To conclude, my main point was that these two methods don't give you the same result. Hope that makes my thougts clearer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It shows that you stopped reading at that point. His point was not that public attributes are just as good or better than getters and setters, his point was that the internals of a class should be as restricted as possible and having getters and setters violates that.
If you actually read the article, you would see this:
```My "default" is to start with a private final member, set only by the constructor. No getter or setter!
If another class absolutely needs to see this member, I think about why. I try to see if there is a behavior that I can expose instead, and create a method for that behavior.```
My points wasn't on good/bad. He said that both ways give you the same result. And this is wrong. That was what I wrote about.
Second, but not least. Getters and setters can also be restricted, if you need that.
Third, there could be dozens of parameteres. Constructor will become huge and I personally don't like that. For that I'd better use a factory, that will garantee to create a valid object. For any other call there's code review to deny them.
Fourth, there's metaprograming in many languages. That lets you use even private members. So I don't see a reason to be so paranoic about that. But private members could give you headache when writing unit tests or changing class with tens of references to that private member.
To conclude, my main point was that these two methods don't give you the same result. Hope that makes my thougts clearer.