To me, the book "A Philosophy of Software Design" was hard to go through.

An example of many frustrations: When talking about a hypothetical HTTPRequest class, the author first shows the "bad" version of an API:

public Map<String, String> getParams() { ... }

And criticism is:

This method is shadow, and exposes the internal representation used by the HTTPRequest class to store paramters. Any change to that representation a change to the interface, ...

Okay, what's the alternative then?

Here is a better interface for retrieving parameter values:

public String getParameter(String name) { ... }
public int getIntParameter(String name) { ... }

getParameter returns a parameter value as a string. It provides a slightly deeper interface than getParams above; more importantly, it hides the internal representation of parameters. getInParameter converts the value of a parameter from its string form in the HTTP request to an integer. This saves the caller from having to request string-to-integer conversion separately, and hides that mechanism from the caller. Additional methods for other data types, such as getDoubleParameter, could be defined if needed.

Ouch.

• If you are bothered by converting String to int, you shouldn't program in Java¹. Whether you like it or not, composing small methods is a way to write Java code. Going against the community norm has a price, and the author doesn't seem aware of it.
• Talking about awareness, I'm not sure the author is aware that Map is an interface and doesn't have to be an "internal representation". This signals the insufficient competence of the author as a Java programmer.

There are a lot like these. Zooming out, the hate for the convention of the Java community, and some of today's programming practices (which are more modern than Java's) permeates throughout the book. It seems that the author is primarily using C++. Also, his suggestions feel more applicable to C++ than to Java.

If so, the author should have used C++ instead of Java. If you don't like Java, why bother? Everyone knows it's a language out of fashion. Maybe the author thought Java was still more appealing than C++ to the general audience or their students? I have no idea.

Because of this dissonance, I have a hard time trusting the author - If the author thinks they know what they actually don't, are his claims actually trustworthy?

But for the sake of a better review, let me mute my loud disbelief.

The problem with this book is that it claims the suggestions are generalizable when they don't. Each programming language has its own trade-off, from the grammar to the runtime to the ecosystem. Things that matter for C++ won't matter in Java, Python, or more modern languages.

My sense is that the suggestions in this book aren't even appropriate for today's C++. However, it makes more sense for thicker API boundaries like OS system calls and RPCs/REST where type systems are limited and programming language matters less. Ideas like "Deep module" and premature generalization can shine in this worldview.

This observation aligns with who is praising the book: Apparently, people around distributed systems and infrastructure platforms like this book a lot. In that world, the programming language does matter less: Things are polyglot and the boundaries between modules are thicker there.

On the other hand, to someone who works on a big monolithic code base written in non-C++, this book is baffling.

If this book were titled something like "A philosophy of platform modularization and API design" and was written with that focus, dropping all the irrelevant rumblings, it could have come out great and I might have loved it³.

It is OK to write code with minimum utilization of the language-specific features. Such an attitude was common until the early 2000s when the mainstream languages were poor. It is still okay sticking that same style today, but I don't think that is what a reader expects from a book published around 2020².

Also, it's fine to criticize Java. In the late 2000s, there was a large disappointment in Java. It accelerated the adoption of "lightweight" languages like Ruby, Python, and JavaScript. It also prompted the rise of modern statistically typed languages like Go and Kotlin.

But if you do criticize, do it well. What "A Philosophy of Software Design" did is less than talking two decades past. As a reader, I expect something better.

Talking about the reader's expectations, chapter 19, "Software Trends", is truly a killer. Why are you talking about OOP, Agile, and Design Patterns as trends now? Pleaaase!

Footnotes

1. You should use Kotlin - I'm kind of kidding.
2. The first edition was published in 2018.
3. Here is another and narrower criticism of this book I wrote before. I won't write another one.