So what exactly is a “leaky abstraction” via getters ? Emphasis on exactly. What is exposing data exactly ?

If you’re looking for exact deterministic discussion of big picture software development ideologies, your question fails at the first pass and you’re going to have to re-evaluate your expectations.

Guidelines are just that. They are not objectively or empirically measurable or able to be conclusively judged on some kind of absolute scale. Similarly, approaches aren’t just right or wrong. A lot of consideration goes into risk mitigation for potential future development effort. Every approach under the sun will hinge on subjective considerations such as (a) your ability to predict future maintenance work (if any) and (b) the consequences of your prediction being wrong.

So what is a “leaky abstraction” via getters?

First, you need to understand what a getter refers to here. As you’ve pointed out, this can take several different shapes, such as direct read access to a field (which therefore isn’t private), a method that effectively gives you the same, or (for some languages) a property that sort of acts like a method getting with a more field-like syntax.

The distinction between these three (or more) interpretations is irrelevant for the advice at hand. The advice, at its very core, is referring to accessing state as opposed to triggering behavior. The details of how you access that state is irrelevant.

This is a secondary argument, following from a previous shift in design philosophy where write access on fields was being revoked specifically because consumers would break things in the object. At the time, not as much attention was devoted to read access, under the supposition that at least this doesn’t break the object’s internal logic. And that’s correct, but there’s a different problem with providing excessive read access to state fields.

The overall idea of arguing against “getters” is that generally having access to these fields (or being allowed to open up access to them if you want it) leads consumers to design their own logic based on these fields, as opposed to considering if that object needs to be extended to include this logic so that it can provide a reusable implementation of said logic that is cohesively closer to what it depends on, so that it becomes easier to account for it if future development effort leads you to need to alter those dependencies in some way.

I do generally agree with the spirit of that advice. However, I find myself strongly disliking all three articles on the subject, because in my opinion they fall prey to oversimplification, strawman arguments and conflating different issues and their different causes and solutions.

I don’t want this to be an article review piece, but to provide succinct responses to the articles’ claims:

• 1 The example is very carefully curated to fit the topic of the post, but its solution opens other doors that it very much ignores.
  • Big picture: dealing with one Bob is fine, but dealing with multiple Bobs with very different goals, aspirations and ideas on what Alice should do is going to be a very different experience for Alice. When you have multiple consumers (or are not in direct contact with them), it becomes impossible to continually re-tailor your implementation to whatever your consumer is asking for.
    • Just to be clear, I’m not saying no solution was needed in this example scenario. It’s good to create an abstraction and make it more change-friendly. But the offered solution creates as many problems as it solves and its underlying assertions are idealistic at best.
  • Small picture: Trade should not hardcode the specific implementation of Cache being used, it disables any kind of inversion of control. Static access is similarly horrible for any kind of testing effort, scoping, concurrency or extensibility. And that’s not even to discuss the inherent horror of needing to now nest classes and interfaces in one another based on two things being tangentially related. How many classes have you seen that nest their own collection logic inside themselves?
• 2 concluding that “You shouldn’t use [..] unless absolutely necessary” is pointless advice on any topic, because it completely sidesteps the core focus (and obvious subsequent question) of how to define when [..] is necessary. Shifting into “well-defined responsibilities”, which again defers any concrete information, also conveniently ignores that offering access to state can at times be a useful responsibility.
• 3 I could nitpick this to death but I’ll keep it short: the example being discussed is a foisted one, where they’re trying to force a decidedly vertical slice into an (equally stubbornly) decidedly horizontally sliced codebase. Yeah, a square peg doesn’t fit snugly in a round hole. That’s not proof that the peg is the wrong shape, nor that the hole is the wrong shape. The only thing you’re proving is that you don’t know what you’re doing and you end up coming across as a bad workman blaming their tools.

“An example app that requires to redirect an user if he is unauthenticated, does not have an account, does not have an email or does have a blacklisted email”

We should indeed consider extending an object rather than writing some new logic somewhere else (which we can only get away with if we have public access to that object’s state in the first place). This is an act of good practice. However, I disagree that the desire to get developers to engage in good practice should manifest itself as telling them to avoid getters.

That’s an act of prohibition (or projected dogma, if not outright prohibition), which is a very slapdash way of teaching good practice not by explaining what it is but instructing others on what to do. I don’t like it and I never will.

It would be decidedly negative for me to only disagree with others, so here’s my take on the information that’s presented, and which parts I think you should focus on because they’re actually correct. I would phrase it as such:

Avoid blindly relying on the availability of publically readable state, and instead assess whether it would be more appropriate to extend the object’s behavior rather than inventing an external way to parse an object’s state.

The overall goal here should be to keep dependencies on another component’s implementation details as low as is reasonably possible, in order to minimize the risk and size of breakage and regression.

It’s not as snappy, but it’s significantly more reasonable, in my personal opinion.

A “getter”, for the purposes above of talking about code maintainability and design, is any method that returns an object that already existed when the call began, that the caller didn’t already had access to (it’s not something it passed in, this, things like that).

This is pretty well-defined this way and much inline with the Law of Demeter, which also tries to tell us to avoid exactly these kinds of methods.

As you rightfully pointed out, when it comes to design though, there’s lots of gray area. Necessarily so, because all design should be driven by context.

Your example of lessThan and hasBlacklistedEmail are good example of “derived” values/objects of existing ones. It feels as though these are not much better. You’re right, they are often not. My rules of thumb are:

• Is the method business-relevant. Will developers, users, etc. use the word ‘lessThan’, when speaking about amounts? If it is, it has a right to exist. If it exists, because I need some information somewhere else. I.e. convenience for the developer, then it probably shouldn’t exist. This comes (at least for me) from DDD.
• Who needs this information? Can I conceivably pull the logic that needs this into this object? For lessThan, probably not. There will be a lot of unrelated places where this will be used. For hasBlacklistedEmail, I don’t know. If it’s one place where I decide to send or not send an email, that logic might be better placed in the Account then, or placed where the blacklist is, for example the Email object, or wherever.

This is a much more subjective topic as you can see.

So what exactly is a “leaky abstraction” via getters?

I struggle with “exactly”. All design is context dependent, so I don’t think “exact” exists.

On a pragmatic note, it doesn’t really matter. Most getters will be “bad” for maintainability, that is why I usually write something like “avoid at all costs”.

There are cases for “getters” though. At places where you just don’t know how the data will be used, it is external to you, like in a library for example.

Again, since in most current projects almost all getters are wrong, I take the rhetorical freedom to just say “avoid”.

A getter is a failure to design an object. It violates encapsulation which is a core principle of object oriented programing.

Now please tell me, how do you design a libraries hash table collection under that philosophy?

The brutal truth here is, much like you can’t have pure functions everywhere, you also can’t have pure objects everywhere. Even SmallTalk had to break down and have you construct things with a menu system because it solved problems the idealized language couldn’t handle on it’s own.

What you can have is an awareness of when you’ve stepped out of an ideal and be ready to face the consequences. I’ve never seen a single purely object oriented program in my life. They all leak.

But, what I have seen is procedural code used to create a safe space for object oriented code, which in turn is used to create a safe space for functional code.

Give me that and I do not object to the purist ideals at all. These rules about what is object oriented are not prohibitions. They’re definitions.

• A getter is a function that returns a value (usually one that’s stored in an object’s member variable).
• A setter is a function that takes a value as a parameter and uses it to modify an object’s state. Or at least, it could modify the state: It can refuse to make the change if the new value fails a validation constraint.

Some languages have syntactic sugar (e.g., C# with its “properties”), where you can write obj.getProp() as obj.Prop and obj.setProp(value) as obj.Prop = value, but behind the scenes it’s still a pair of functions.

Often, a getter/setter pair corresponds to a private variable, but this isn’t required. For example, you could pack multiple bool properties into one int bitfield to save space.

IHMO, there’s nothing wrong with getters/setters or properties per se. Sometimes, it’s perfectly natural to think in nouns (properties), and sometimes it’s natural to think in verbs (methods).

Perhaps what people are actually complaining about is the newbie programmer mistake of assuming that every variable needs a getter and setter, effectively creating public variables with extra steps. You should only expose getters and setters when it makes logical sense to do so.

For example, in banking software, it makes perfect sense to have an Account.getBalance method, since your customers will often want to check the balances of their accounts. But Account.setBalance would be meaningless, because you can’t just declare “I want $1000 in my checking account” without more context. Account balances are updated by moving money to or from somewhere (either from another of your accounts, someone else’s account, or the teller/ATM’s cash drawere), and you have to ensure that every decrease in acct1.balance is balanced by a decrease in acct2.balance. So instead of a setBalance() method, you use transfer(), deposit(), or withdraw() to update account balances.

Also, you should avoid unnecessarily exposing irrelevant implementation details. The user of a DateTime class shouldn’t care whether the object internally contains a 64-bit integer count of the number of microseconds since the Unix epoch, separate year/month/day/hour/minute/second fields, or a String in ISO 8601 format. What matters is whether they can use the class to answer questions like “Is today Friday?” or “How old is a person who was born on December 21, 1982?”. If an internal state variable isn’t relevant to the information that your class’s users would care about, then it shouldn’t be exposed with get/set.

I’m late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a “getter” because its not what it does, but how you use it that’s the problem.

When people say “getters are bad” what they mean is you are writing in an Anemic Domain Model style where you put your methods on services and read data from your objects. ie.

public class Account
{
   public int Amount {get;set;}
   public string CurrencyCode {get;set;}
}

public class CashMachine
{
   public AddFunds(accountId, amount)
   {
      var a = repo.GetAccount(accountId)
      a.Amount += amount;
      repo.Save(account);
   }
}

And you should be writing in an OOP way. ie.

public class Account
{
   private int Amount
   private string CurrencyCode
 
   public AddFunds(amount)
   {
      this.Amount += amount;
   }
}

With no public Amount getter, you would be forced to use the OOP approach. So “avoid getters” is a good general rule to flag up when you might be straying from OOP.

However.

If you really don’t expose any properties at all you start doing other things which are also considered bad. ie.

public class Account
{
   private int Amount
   private string CurrencyCode
 
   public Save() //ooo coupling to datalayer!
   {
      this.database.execute("insert into...");
   }

   public Display() //ooo coupling to presentation layer!
   {
      this.detailView.Update(...
   }
}

What’s happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like “avoid getters” meant to help you understand the principle behind that style. They aren’t meant to be taken to the nth degree and they aren’t supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he’s saying “You can take the rule further than you think, push yourself harder to write in the OOP style”

This is really a challenge to the reader rather than a proof of OOPs superiority over other styles. Try putting Display() on Account is it really that bad? look at the advantages, don’t assume it won’t work.

I’m my view people often don’t try things out, they take a bit of each style that they like and dismiss the rest “it would never work!”, “the example is a strawman!”. You need to take some time and try out what the article is suggesting before going back to everyone’s favourite the superior ADM style

So what exactly is a “leaky abstraction” via getters

For added emphasis, let’s change your Account code to

final String _email;
String get email => _email;

This leaks the information that

1. Account contains the email (imperfect, but not too shocking)
2. The email is stored as a String (this is bad)

Users of Account know that email is concrete, a String, and will write code to check the length and split on an @ sign and stuff like that. It will be very difficult to ever change _email to something “better”, like an Email. Your abstraction has leaked and it is no longer abstract.

Even if you had used an Email type, there is some leakage, though obviously not as bad as for a String.

I think this falls under a couple of bullets from Joshua Bloch: Bumper-Sticker API Design

Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best.

When in doubt, leave it out. … You can always add things later, but you can’t take them away.

Leaving out getters, to a “reasonable” extent, is good OOP, and good API design. And setters are even worse – in general, avoid them like the plague.

Your issue appears to stem from a foundational problem of object-oriented analysis, and the confusion with getters might be a symptom of deeper design considerations. Having encountered similar scenarios throughout my career, but without knowing your exact requirements, I can offer insights that might clarify your approach:

1. The “User” often represents an external actor rather than a system-managed entity. Typically, it should not be modeled as an object in your system.

2. If the “Account” is unauthenticated, or does not have an email, then it should be the one redirecting the user.

3. It’s beneficial to employ polymorphism where object behavior varies significantly:

   • UnauthenticatedAccount()
   • InvalidAccount()
   • EncryptedAccount(encoding: BasicAccount())

let account: Account = UnauthenticatedAccount()
account.showProfile() // redirect

Again, this depends on your specific requirements, however.

Anyway, the key is not just about eliminating getters but ensuring that objects manage their own data and behavior. This means designing your objects’ interfaces around what they can do for clients, rather than exposing their internal states via getters or indirect methods.

Plenty of answers why getters are good or bad. But not what they are, which is the question.

In C, structs have fields that anyone can access. Same for structs and classes in C++, except they are called “instance variables”, and in classes they are usually private, so they cannot be used outside the class.

The simplest getters or setters are public functions that set the instance variables or read them and return their values. So no difference whatsoever to instance variables except slightly different syntax and they are public. And there comes big criticism: If it’s a bad idea to access the instance variable, then using a getter or setter instead doesn’t make it any better.

Slightly more complicated, you may have a getter that returns a reference or a const reference to the instance variable. Which allows you to modify the instance variable even later, after you may have forgotten the reference to the object. Just as bad as another getter or setter.

Then people write more complicated getters and setters. Take a rectangle with width, height and area. Setting the height makes the area invalid. So the setter for height could change the height and area instance variable. Or the getter for area might have no instance variable at all but return width * height. Or a button object might have a setter for “title” which stores the title, but would also redisplay the button on the screen, possibly changing the screen layout. That’s a functionality that you want, and there is no reason to call it anything other than setTitle. Still a setter.

So getters/setters are functions with the right names, and making a standalone change to the object, that is a change that can be performed on its own, and doesn’t require other setters to work correctly.

A getter in this context is any method that returns an object that already existed when the call began. (From Robert’s answer)

statement

By definition a method on an object that has a return value will leak state or derived state from either:

1. The object
2. The argument
3. The global scope

Assuming you are not crossing your program boundaries (with example: network calls), we can order data encapsulation as such:

0. direct access to state

Here there is no encapsulation method used.

class A {
  final public B b;
}

This allows direct access with a.b

1. Getters access to state

( ## 1. Technical pure getters access to state)

Here a getter in technical terms (as defined by the language you use) is used.

class A {
  final private B _b;
  B get b => _b;
}

This still allows a.b (or variants from your language).

( ## 1. Pure getters access to state)

This is the same as technical getters but uses a method with no arguments to “hide” the fact that this is a getter

class A {
  final private B _b;
  B giveB() => _b;
}

You access state via a.giveB()

( ## 1. introspectional access to state)

For the sake of completness:

class A {
  final private B _b;
  dynamic giveProperty(String propertyName) => propertyName == 'b' ? _b : null;
}

2. Derived state access

Here we are not directly accessing the state of an object but computing a new object based on the object own property because there is no argument.

If we did not use the object properties, then the method would not be a good fit for the object (it could have been static method for example).

So, because a new value is created we can’t say that the object is leaking state directly. However some breadcrumbs of information is still leaking through the computed result, by definition, since the object properties are used to compute a new value.

class A {
  final private B? _b;
  Boolean hasB() => _b != null;
}

This would be in line with Robert explanation, inspired by the law of Demeter, if you consider a Boolean an object (it does not matter if it’s a primitive technically in your language).

class A {
  final private B? _b;
  final private Boolean _hasB;
  Boolean get hasB => _hasB;
}

2. Derived state access through parameters

Here the object properties and method parameters are both used to compute a new value:

class A {
  final private B? _b;
  D computeD(C c) => _b.doSomething(c);
}