Do you like coffee? This episode is all about coffee. Or, rather, it's all about making coffee. This episode introduces our series on the SOLID principles of component design. In this episode Uncle Bob will tell you just what components are, and how they came to be. We'll learn how loaders evolved into linkers that evolved into linking loaders. We'll learn how object files evolved from absolute, to relocatable, to linkable, to dynamically linked components. Then we'll do a deep investigation of the Coffee Maker case study. We'll learn the requirements and the API. We'll see how not to design it, and then we'll see a good SOLID component-ized design. We'll see how boundaries are created and crossed with the Dependency Inversion Principle. We'll see how high level modules are identified with the Single Responsibility Principle. And we'll watch yo-yos go up and down as we traverse up and down the layers of abstraction. By the time we're done we'll have laid the foundation for the next episodes on the principles of component design. So, grab a nice hot steaming cup of really strong coffee, sit back, relax, and enjoy the buzz because were about to spend the next hour brewing component principles.

Sticky, Icky, gooey! Cohesion. That's what this one's all about. Component Cohesion. How and why do components cohere? What are the good forces of component cohesion, and what are the bad forces? Which classes belong together in components, and which should be kept apart? Oh, and why do White Dwarf stars go Supernova? In this episode we're going to explore the three principles of component cohesion: The Release Reuse Equivalence principle The Common Closure Principle The Common Reuse Principle We'll learn about the goal of independent deployability, and why that goal causes certain classes to belong together, while other classes don't. We'll also learn about the forces of false cohesion that tempt us to group classes together into ineffective components that aren't independently deployable. We'll see, first hand, the erie connection between the component principles and the SOLID principles. We'll see how components are governed by release procedures, by actors and their responsibilities, and also by how much knowledge they present to their users. And we'll discover that the component structure of a system is a function of it's maturity as well as of it's behavior. We'll see that the component principles have a certain mutual exclusivity that creates a tension in the component structure. So get a rag and some Acetone, because we've got a lot of gooeyness to deal with, as we slurp our way through the topic of component cohesion.

Stop all that giggling and get your minds back out of the gutter. It's Component Coupling people, Component Coupling. In this video our intrepid cast of characters will explore the principles that govern the relationships between components. Those principle are: The Acyclic Dependencies Principle. The Stable Dependencies Principle. The Stable Abstractions Principle. In this lesson we'll learn about the Morning After Syndrome, that hideous disease that affects large teams and causes them to step all over each other. We'll show how a large system can be safely and effectively managed by keeping the dependencies between the components free of cycles. Then we'll take a look at the concept of stability. What makes a component stable, and why should we care? What effect does stability have on the dependencies between components? Then we'll look at abstractness. What makes a component abstract? How does abstractness impact on the couplings between components? Then we tie it all together. What is the relationship between stability and abstractness? How can we use that relationship to free our stable components from rigidity? Finally, we boil it all down into numbers and metrics. We derive a set of simple mathematical expressions that describe the relationships between components, and provide numeric measurements of how well those components conform to some of the SOLID principles. So, don your enchanted armor, get your iron picks and diamond swords ready, and get out of bed, because the sun is about to rise on the world of Component Coupling.

Oh, so you want an example eh? You want something real? You're tired of all the theory and lecture. You got through all those videos about the component principles, and now you want to see how they're actually used. Well, do I have good news for you! Because that's just exactly what this episode is all about. We call it the Component Case Study and it's all about studying cases. We're going to study big cases, small cases, round cases, square cases, suit cases, hat cases -- all kinds of cases. By the time you're done with this video you're going to know cases inside and out. No, that's wrong. It's not about cases. It's about components. It's about component principles. In fact it's a detailed examination of just how those principles are used to solve a real problem. The problem we tackle is the Payroll problem from Episode 14. Remember back in that episode we applied the SOLID principles in order to create an object oriented design that partitioned the problem into classes and relationships? Well now in this episode we're going to take those classes and we're going to apply the component principles to them, creating an architecture of independently deployable components. But it's not just going to be as simple as that. Oh no! First we're going to look at lots of wrong ways to break the problem into components -- ways you might even recognize from past projects. We're also going to spend a considerable amount of time talking about, and using, component families as an organizational concept. So make sure your cases are all packed and ready to go; because we're going to study those cases as we embark upon: The Component Case Study!