Clean Code: SOLID Principles
14. Solid Case Study
By Uncle Bob, 43m

OK, this one's a little different. No science lesson. The tone is a bit more serious. (a bit more.) It's the conclusion to the series on the SOLID principles. In this episode we look again at the Payroll Example from Episode 7; but this time we do so in the light of the SOLID principles.

In this episode we start from use cases, and work through each of the principles to create a design. We break up the use cases by using the SRP. We start to build the architecture using the OCP. We find LSP issues to solve in the complex polymorphism hierarchies. We find the ISP lurking in factories. And, of course, the DIP is everywhere.

As we walk through this case study, we examine each principle in depth. We allow the principles to illuminate issues in the design, and then we discuss several ways those issues can be addressed. Bit by bit we piece together the design.

Then we close by taking a lesson from Joel Spolsky when he criticized these principles several years back, without really knowing what they were.

So sharpen your pencils, you're going to need them, because this is an in-depth review and case study of the SOLID principles.

13. The Dependency Inversion Principle
By Uncle Bob, 58m

And now, at last, it's time for the Dependency Inversion Principle -- the final principle in the SOLID suite.

Go back in time with Uncle Bob to 1979, when he was just a noobie software developer with only 6 years experience. Walk with him through the tale of telephone test equipment using 8085 microprocessors with 32K of RAM and 32K of ROM. See how he first discovered the magic and power of inverting source code dependencies in order to turn those ROM chips into independently deployable components.

Then hop into the time machine to the early '90s when Uncle Bob was becoming an accomplished C++ programmer. See how he, and his team, struggle, and at first fail, to create a huge reusable framework. Watch as he discovers the key to reuse, and to building frameworks that many applications can reuse.

In this episode we'll learn what dependencies are. We'll study the difference between source code dependencies, and runtime dependencies. We'll learn why that difference is important, and we'll learn how to invert certain key source code dependencies so that they oppose their corresponding runtime dependencies.

Then we'll spend some time looking at two case studies. First we'll look at IO drivers, and how they use dependency inversion to create device independence. Then we'll look at the good old furnace example, and see how dependency inversion allows us to separate high level policy from low level detail in order to create a plug-in architecture.

So get ready for a wild ride through time and technology and we DIP in to the Dependency Inversion Principle.

12. The Interface Segregation Principle
By Uncle Bob, 1h 5m

There may be no I in TEAM, but there sure is an I in SOLID, and that's what this episode is all about: The Interface Segregation Principle.

I remember, long ago, a nemesis of mine on comp.object used to accuse me of being a racist because I used the word "segregation" in this principle. He also took note that I called a particular design pattern "TaskMaster". Ah, Elliott, I sometimes miss your thorn in my flesh.

In this episode we're going to talk about the problem of too much knowledge. We'll show the strange backwards dependency that happens when classes know too much; and the problem that backwards dependency causes.

I'll tell you the story about how the Interface Segregation Principle came into being. It's a story about a company that had a big build-time problem. I'll show you the bizarre solution we discovered to fix that problem; and tell you why soot was so important to that discovery.

We'll talk about fat classes -- classes that have too many methods, and too many dependents. We'll discuss the problems they cause, and how to resolve those problems.

We'll watch a young novice under the tutelage of her master as she struggles through the ATM case study and investigates why too much knowledge harms system structure.

Then we'll investigate the physical structure of interface segregation, and once again assert the importance of the boundary between the application and main.

Finally, we'll talk about the principle behind the principle, and why this principle which on the surface of it seems to be about static typing, is actually not about static typing at all.

So pack the kids in the car, strap the bikes on the roof rack, and cram the tent in the trunk, because we're about to drive into the rugged territory of the Interface Segregation Principle.

11.2. The Liskov Substitution Principle
By Uncle Bob, 32m

This is Part 2 of Episode 11

Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming!

That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++.

Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest".

Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages.

Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate.

Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive.

So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

11.1. The Liskov Substitution Principle
By Uncle Bob, 55m

Make sure to watch Part 2 after watching this episode!

Oh no! Not the Liskov Substitution Principle! Not that! Please! Anything but squares and rectangles and type and subtypes. Katie, bar the door! Mabel, hide the kids. Somebody run for the Marshall. Tell him: LSP is coming!

That's right, in this episode (after a brief diversion through wave/particle duality) Uncle Bob takes on the dreaded Liskov Substitution Principle. He'll tell you all about the history of the theory of types, including Russell's paradox, and Turing's revelations. He'll show how this theory influenced early computer languages like Algol, Fortran, Cobol, and even C++.

Then Uncle Bob will introduce you to Barbara Liskov, and the principle of substitutability that she wrote about back in 1988. He'll describe that principle in terms of modern languages like Java and Ruby, and he'll show how it relates to Martin Fowler's code smell of "Refused Bequest".

Then he'll dive into the favorite old conundrum of the squares and rectangles, and he'll show that inheritance is not what it appears to be, and certainly not what you have been told it is. He'll teach you about the Principle of Representatives and the implications it has for sub-typing and inheritance. And you Ruby programmers won't get off scott free either! He's got plenty to say to you about subtypes in dynamic languages.

Next, Uncle Bob will show you the cost of violating the LSP and will present heuristics and techniques for identifying potential violations, and for correcting existing violations. On the way he'll talk about the dreaded 'if instanceof' statement. He'll show why it is dangerous, and when it is appropriate.

Then, true to form, Uncle Bob will present a case study of a subtle LSP failure, and the horrific consequences it causes. You won't want to miss this part. By the time he's done you'll be hunting all through your code trying to find and repair potential LSP violations in order to prevent all the nasty 2AM phone calls you will otherwise receive.

So let the horses out of the corral, batten down the hatches, and run for the storm cellar, because LSP has arrived!

And remember to get Part 2 when you are done with Part 1!

10. The Open-Closed Principle
By Uncle Bob, 1h 2m

The Moral Center of Software Architecture.

That's how Uncle Bob describes the Open-Closed Principle (OCP). In this episode you'll learn all about Bertrand Meyer's remarkable insight into Object Oriented Design and the motivation behind good Software Architecture.

We'll discuss how it's possible for the source code of a system to be open for extension, but closed for modification. Then we'll show you how to construct designs that conform to that principle.

Next we'll look at a truly awful design that violates the OCP and we'll show how that violation creates the design smells of Rigidity, Fragility, and Immobility.

Then we'll present a truly elegant and beautiful design that conforms to the OCP. This design will startle you with it's essential simplicity; dazzle you with it's suave construction; enamor you with it's incredible flexibility. After seeing it, you'll begin to believe that software can be open for all extension and yet closed for all modification!

Then we'll break your heart by showing you why the promise of the OCP is, in fact, a big lie. We'll tear that elegant design to shreds, and we'll show you why all that protection it claimed to offer was an illusion that depended upon prescience and perfect foresight. In the end we'll shatter your hopes and dreams in software design.

Then we'll resurrect those hopes and dreams by describing a development process that helps to restore the truth behind the promise of the OCP. We'll show you that you can, in fact, make designs that conform to the OCP, if not in whole, then at least in part. We'll describe the disciplines that will help you to take the greatest advantage of the OCP.

So sit yourself down and settle on in, because after we learn about the Quantum Discontinuity, we're going to open the can of worms called the Open Closed Principle.

9. The Single Responsibility Principle
By Uncle Bob, 1h 9m

In this video Uncle Bob will take you on a deep dive through the Single Responsibility Principle. After a little General Relativity, you'll learn just what a responsibility is, and how it relates to the users of the system and the roles that they play.

You'll learn about the primary value of software, and why that value is not what you'd expect. You'll also learn how the proper allocation of responsibilities to modules impacts that value and means increased profits for your business.

Uncle Bob will teach you how misplacing responsibilities can lead to design smells like Fragility and Viscosity. He'll show you the importance of separating responsibilities into different functions, classes, and modules. And he'll demonstrate different techniques for achieving that separation.

Next, he'll walk you through several different Java functions and ask you to find the single responsibility violations. Then he'll show them to you and recommend ways to separate them.

Finally, he'll walk you through the case study of a simple application, from inception to delivery. He'll show you how to find the responsibilities; and, following the principles of architecture from Episode 7, how the system can be designed so that those responsibilities are separated. He'll also show you where to get the code so you can study it later.

So get yerselves saddled up and rarin' to go because yall're 'bout to stampede into The Single Reponsibility Principle. Yee Ha!

8. Foundations of the SOLID principles
By Uncle Bob, 53m

In this video Uncle Bob begins his exploration of the S.O.L.I.D. principles, by beginning at the beginning, and laying out their foundations. This is the first of several new episodes that will do deep-dives into the principles one-by-one.

We begin with the question: "What is Design?". We make the case, based on Jack Reeves' famous 1992 paper, that the design of a system is best captured by the source code. That all other forms of design documentation, regardless of their usefulness, are preliminary and/or ancillary.

If the design of a system is it's source code, then cleaning the source code is cleaning the design. But what are the symptoms of poor design? How can we know when the design of our systems is starting to degrade? To answer that, we take a harder look at the Design Smells of Rigidity, Fragility, Immobility, Viscosity, and Needless Complexity. How can we identify these smells and clean them before they become a significant problem?

Next we watch a batch of code rot. We start with a pleasant and clean design and watch as change after change degrades that design into a festering mass. Then we study an alternate design that does not rot when the same changes are applied. We investigate the difference between those two designs and discover the principle that underlies all of Object-Oriented Design. We do a deep dive into the history of OO, and derive a new and unambiguous definition of OO based on Dependency Management.

Finally we take a brief look at the S.O.L.I.D. principles which will be the topics of the next several episodes.