What stood out to you as the key takeaway from this chapter?

I believe the overall point Martin is really trying to make here is that developers should not default to exposing data, but to hiding it and exposing behaviour.

Why … do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?

I agree with this. However, I think Martin makes a very strange and unconvincing argument in this chapter about how to approach this problem. It seems to boil down to “there’s 2 ways to do things” without much critical insight or pragmatism. Martin states:

Objects expose behavior and hide data. This makes it easy to add new kinds of objects without changing existing behaviors. It also makes it hard to add new behaviors to existing objects. Data structures expose data and have no significant behavior. This makes it easy to add new behaviors to existing data structures but makes it hard to add new data structures to existing functions.

I think this is very broadly true, but in reality there’s going to be a lot of situations where you have objects that expose both behaviour and data. For example:

• Your object needs to expose its data to something (like a persistence layer) but otherwise only contains behaviour. Sometimes this can be abstracted away, but not always.
• Your data objects might have validation, or might compute some data from other values it owns. Perhaps you might say “aha, well it’s not a Data Object then!”, but Martin seems more concerned about abstracting an object’s internals. So if the class exposes its internals, and provides no behaviour other than validation, is it an Object or a Data Structure?

We’re also ignoring a lot of situations where it’s not harder to add either behaviour or data structures. There’s a lot of stuff that falls into the cracks between these two definitions for valid reasons.

I think the takeaway for the reader is simply to consider the data and behaviours we expose with our objects. I’d argue Martin goes a little too far with the assertion that failure to write classes that fall into the above groups is a failure on the part of the developer.

[Objects with data and behaviour] are the worst of both worlds. Avoid creating them. They are indicative of a muddled design whose authors are unsure of — or worse, ignorant of — whether they need protection from functions or types.

I believe I understand the argument that Martin is trying to make, but these comments fundamentally ignore the realities of writing code where you sometimes have to make data available to other objects. Martin knows this, because he talks about it in Clean Architecture.²

Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions.

On Interface Adaptors

Similarly, data is converted, in this layer, from the form most convenient for entities and use cases, into the form most convenient for whatever persistence framework is being used.

This is not possible if you don’t expose the data inside the Entities. A case might be made that “you don’t expose the data inside the Entity, you expose some DTO that is persisted, and rebuild the entity from that DTO”. Ok, so the data inside that DTO is exposed instead, and now our Objects expose the data in some other format. What have we gained?

I feel like more practical advice here would be to recognise that there’s a spectrum here with Object at one end and Data Structure at the other. Developers should understand what this means and aim for the appropriate target.

Do you feel like you separate objects and data structures logically when writing?

I think I would prefer to phrase my position as; “I try to abstract away as many of the implementation details as I can for any given object”. I find that this usually produces far more things on that Object side of the spectrum that it does Data Structures, although they do still exist. If I am writing them, they will almost always take the form of what Martin calls a “bean class”.

Beans have private variables manipulated by getters and setters. The quasi-encapsulation of beans seems to make some OO purists feel better but usually provides no other benefit.

I’m utterly perplexed by Martin’s sudden lack of interest in abstraction here. Of course there are benefits to writing the code like this.

• You can more easily change the implementation of the data, because you don’t interact with it directly.
• You have more control over access to that data (e.g. thread safety).
• You can add validation if it becomes needed.
• You can change types and add a mapper for the original accessors.
• You can trivially extract an interface if needed.

I mean, the list goes on. I would wager most experienced developers have at some point changed the internals of such a class in a way that allowed the original accessors to work with the new data, limiting the amount of changes required.

Returning to the original question, there are two things that I see relatively often in PRs that could be improved on by thinking more often in terms of data structures and objects.

Firstly, custom View code. I frequently see Views that expose way too much of the underlying view code via methods, rather than narrowly scoping the interface to just do what the View was designed for. For example, given a view that shows either an Error or a Warning, it might expose methods like setColor(int color), setIcon(Drawable icon), and setText(String message). If the use case is that we show a specific icon and color for warnings and errors, then I’d probably suggest this is changed to setWarning(String message) and setError(String message), with each method setting the color and icon appropriately.

The other scenario I see a lot is an unwillingness to create small data objects for passing groups of related data around. By ‘related’ I mean data that is often passed at the same time, or is a ‘subgroup’ of a larger object. This is more often referred to as Primitive Obsession.

People new to objects usually are reluctant to use small objects for small tasks, such as money classes that combine number and currency, ranges with an upper and a lower, and special strings such as telephone numbers and ZIP codes. ³

Are there any other considerations or tradeoffs you don’t think were covered here?

I don’t think Martin really explores what valid reasons are for exposing data from a class. We know about DTOs, which are for passing data around. The first example of the chapter claims that it’s better to expose a method getPercentFuelRemaining() than to expose the methods getFuelTankCapacityInGallons() and getGallonsOfGasoline(). But this implies that we have an understanding here of exactly what data we need to expose.

…we want to express our data in abstract terms.

The implication here is that our object’s data is the current and max capacity, and that we can abstract that away from the caller by providing a useful abstraction. But what if the caller needed the max capacity? If we’re really abstracting the underlying data, we would provide these methods via an interface and the caller will have no idea which of the above methods are part of the underlying data (if any). Is it a bad example, or are we glossing over the idea of what it means to abstract data?

What’s your take on the approaches he suggests here for good error handling?

I think the high-level advice here is spot on. Use exceptions over error codes, provide context to your exceptions, etc. It does seem to go off the rails a little bit in two areas: Unchecked Exceptions and null handling.

Let’s start with Unchecked Exceptions. It’s true that other languages manage just fine without Checked Exceptions, and you could use Unchecked Exceptions everywhere if you wanted to. Of course, you could also run your whole application on a single thread if you wanted.

If you throw a checked exception from a method in your code and the catch is three levels above, you must declare that exception in the signature of each method between you and the catch. This means that a change at a low level of the software can force signature changes on many higher levels.

This seems utterly bizarre to me. In Java, you can pass an Exception to another Exception’s constructor as the cause. The idea here is to express a lower-level exception in higher-level terms. It’s intellectually dishonest to ignore this. Nothing says you have to pass low-level exceptions to high-level code.

For example, if you have a comms layer, many things might go wrong. Perhaps you have a complex multi-stage upload process. It could go wrong for several reasons: perhaps there’s no transport available, or a security exception is thrown. Maybe the file isn’t there! We might not expect our top-level code to deal with all of these things. Perhaps it only needs to handle the situation where the upload fails. So your low-level code might throw one of many exceptions, which will be caught and re-thrown as a more general exception to higher level code.

Of course, all of these could be unchecked exceptions, and a diligent developer could just keep track of all of these potential specific exceptions and add catches/re-throws to ensure it’s caught by the top-level general catch block. Sure, we’d lose the ability to detect a missed exception at compile time, but any issues will probably be caught in testing, right? Or perhaps both checked and unchecked exceptions have valid use-cases.

With respect to returning and passing null, I feel that this is a horse that’s been beaten into a fine red paste at this point. Java has null, which almost always means ‘undefined’. There are a lot of situations where you might want this. Martin⁴ makes a lot of noise about removing null checks and instead adding other checks that throw different exceptions. To what end?

That said, I’d be lying if I said I didn’t partly agree. I do frequently throw rewrite methods so that there’s a variant that doesn’t require null being passed, but then it’s just inferred; I’ve not really changed anything. Sometimes I’ll write code that throws an IllegalArgumentException, just to make it throw the same type of exception on any type of bad argument. But I wouldn’t jump through hoops or make rules about avoiding null. Compile-time checking for null is a nice feature in languages like Kotlin, but we don’t have it in Java.

Are there any other thoughts you personally have on approaches to error handling?

Null-checking is a weird thing. If the value can be null, then we only need to null check in a sensible way - where we can recognise null as a valid non-error value. If the value can’t be null, and we have encounted a null, then we’re faced with one of two paths:

1. We have a error value here that we can’t deal with. We need to throw an exception of some kind. What’s wrong with NullPointerException? It’s usually clear and to the point.
2. It can’t be null, but there is an acceptable non-null default of equivalence that we can use, such as an empty collection. So why not just replace the value?

So in the latter case, we can null-check and pass, sure. But in the first case, just let the code throw the NullPointerException. Seeing code that checks for null then logs it and then limps on… no, either something has gone wrong and we should throw an exception, or we could just set a default value.

Nullability is a thing in Java. The null cat is out of the coffee bag. No amount of rules about “not returning or passing” null will save you from this.