As a set of object-oriented programming design principles, SOLID is pretty lacking.

Did you know that…

• the Single Responsibility Principle doesn’t clearly define "responsibility" so most developers just keep de-coupling until the end of their sprint?
• the Open/Closed Principle says you can’t change source code, so thus your only alternative is to use a mess of inheritance and abstract classes to make stuff flexible in advance?
• Barbara Liskov didn’t have anything to do with the Liskov Substitution Principle and that the principle amounts to "inheritance is a thing"?
• the Interface Segregation Principle is essentially functional programming feature envy by Java developers?
• all that XML developers wrote in the 2000’s was because of the Dependency Inversion Principle, and it turns out that just writing simple code is actually better?

Find out more problems with these principles, as well as new ways to get angry about agile nonsense like YAGNI

Table of Contents

1. Stop Validating Your Experience and Start Questioning Authority (Read excerpt…)

2. Literally Anyone Can Lead Thoughts

3. The Five Rules of Good Design That I’m Certain You Haven’t Looked Closely At

4. SOLID is Not Very Solid After All

5. This is Not About Uncle Bob

6. Single Responsibility Principle, or: Chasing Three Lines of Code Over 18 Files Just to Make One Change

7. What Exactly is a Responsibility?

8. Five Responsibilities in Five Lines of Code

9. Change, For Lack of a Better Word, is Good

10. The Second Stage Turbine Blade

11. Each Line of Code, It’s Own Responsibility, Belongs Nestled Safely in its Own Class, Docker Container, or Microservice.

12. Incoherent Ramblings

13. Software Design Isn’t About Counting Up Things

14. Open/Closed Principle or: The Test Of Have You Actually Read SOLID

15. Inheritance

16. The Origin Story You Never Knew You Didn’t Want

17. Version Numbers are For Marketing, Right?

18. Liskov Substitution Principle or: Don’t Use The One Thing Stroustrup Actually Didn’t Want in C++ Anyway (Read excerpt…)

19. Papers We Love But Have Not Really Read

20. Papers We Don’t Love But Had To Read As Research For This Book

21. Interface Segregation Principle or: The Reason Functional Programmers Are So Damn Smug

22. Hacking Around Bad Design

23. Ever Do Functional Programming in Java?

24. Java Loves Interfaces So Much That It Does, In Fact, Marry Them

25. Dependency Inversion Principle, or: Why 2000’s-era Java Code Was Mostly Written in XML

26. Objects are All About Re-use. Just ask CORBA…I mean EJB.

27. I Will Make FizzBuzz Enterprise Edition Look Like Rails

28. .java files are for Clean Coders Only

29. Agile’s Infantilizing Sloganeering Diminishes Us All

30. DRY - Don’t Repeat Yourself. Do Not Repeat Yourself. Stop. Repeating. Yourself.

31. KISS - I’m not Stupid, and Neither Are You

32. YAGNI - You Aren’t Gonna Need It (except when you are)

33. The Simplest Thing That Could Possibly Work Would Be Actually Working Software

34. No Big Design Up Front So Why Aren’t You Coding Right Now? Start Coding. Now. Just Type “v” “i” “m”…

35. User Stories Paint a Picture of Fairy Tales and Form Validations

36. Well, Now What Do We Do?

37. Some Solid Advice

38. Some Words of Warning

39. Not Convinced?

40. Colophon or, How To Make Your Own e-Book!

Just tell me this table of contents doesn’t make you want to shell out $5.99 right now!

Oh, you want to spend more? Buy it print for $6.99!

What You Get

The book is about 70 pages long (in print or in PDF), so it’s a quick read!

The ebook includes a PDF, an EPUB, a MOBI, and a Markdown/text file so you can read the book in whatever way you see fit for only $5.99!

OR

Get your own physical paper book, beautifully typeset. It’s a fine addition to any bookcase or Little Free Library. It’s only $6.99.

I’m afraid I can’t make a bundle where you get both for a collective discount.