Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

10
  • 8
    Robert Bräutigam (author not only of the first, but also of your 3rd referenced article) is an ideologist proposing a school-of-thought where "Tell-Dont-Ask" is taken to the extreme (I think he will agree on this if you ask him). Be aware there are other school-of-thoughts. Commented May 10, 2024 at 6:14
  • 3
    To add to Doc Brown's point, I also want to be open here and admit that Robert and me have butted ideological heads over these things before. Without trying to devolve it into right and wrong, I think it's fair to say that his take on things is radically different. It is difficult to marry this up to a lot of other guidelines and conventions you're going to find on the subject. Inbetween article 1 and 3 being Robert's, and article 2 being decidedly undecided and vague, it's difficult to distill a general understanding of these concepts from what is essentially one radical position. Commented May 10, 2024 at 6:28
  • 4
    It's touching that I left a lasting impression, thanks guys :) I wouldn't call myself an "ideologist" though. I'm not an academic. I've been writing "enterprise" software since the late 90s for a living, and I think this is what works. Do not conflate rigorousness with dogmatism. Commented May 10, 2024 at 20:58
  • 1
    There was a time when there wasn't special syntax for getters and setters - there were just methods (and people would write getSomething(), setSomething(val)). The terms "getter" and "setter" originate from those days. Even today, in languages that do have special syntax, the compiler usually turns those into methods under the hood. It makes no fundamental difference, design wise. The problem is not accessing properties, the problem is that you're making callers rely on the exact structure of your internal fields (assuming you want some flexibility there). That breaks encapsulation. Commented May 11, 2024 at 20:45
  • 1
    Think of what they are saying as a challenge of sorts. Trying to write working code with no getters whatsoever is a good design exercise (and a somewhat advanced one, I might add), as it forces you to figure out how to get things done by relying on higher-level methods (of your design), and by passing in lambdas or objects as parameters. Avoiding getters is not necessarily something you'll strictly apply in practice, but without this insight, you don't even have the option to strategically chose when to do it, nor the knowledge what to do instead. Commented May 11, 2024 at 22:53