Lots of SOLID advice (sorry, had to) , though I do think that the fact that it's written for early 00s java limits it in that it doesn't really address functional map/filter/reduce (select/where/accumulate) type stuff that more modern versions of java and pretty much all other languages allow for.

Main takeaways:
1. Names are important.
2. Functions/classes should be small
3. Comments on something that's not a public API are out of date the moment they're written. Just go crazy with privately named functions.
4. Refactor a lot
5. Inversion of Control / Dependency injection is neat - But really this was written at a time when the DI configuration step was terrible to write. I think .Net core handles this stuff really well now, and I'm sure the java frameworks do just fine.
6. Functions with a lot of arguments are terrible, maybe even evil

I don't know that I'd follow this to a tee. Conceptually I think the rules are fine, although I'm not sure I love excessive private function use with forgoing function arguments for private attributes. I understand that within an object, private attributes are fine things to go side affect crazy on, but I think that with web controller type request/response stuff, that sometimes it's just a little more straightforward and testable to have the endpoint method own the scope of the variables and just output the right thing without mutating the state of the object. Obviously the services it calls would still be injected into private attributes. Maybe in other contexts/application types it would totally make sense to keep it a bit more heavily OOP and encapsulated and all that good stuff.

Overall I think it's a good book and a great starting point for thinking about code styles, readability and consistency.