And so we begin our exploration into design patterns. We begin by talking about the overall concept of design patterns. What are they, and what are they good for? Next we do a quick overview of the GOF book; and we'll find out why it is one of the most important books to be written within the last three decades. Then we put our heads down and focus tightly on the Command pattern. We learn that the command pattern is a way to decouple what is done, from who does it. Next we find that it also helps us decouple what is done from when it is done. Next we look at Undo and Redo, and how the Command pattern makes these features almost trivial to implement. Finally we look at the actor model; a way to support hundreds or even thousands of threads in a memory constrained environment. So hold on to your GOF because Design Patterns are about to begin.

So. Now it's time to talk about Factories. Factories. Lots and lots of Factory patterns. And no XML. In this episode we'll introduce three patterns in the family of factories. Factories! Lots .... And no XML. First, we'll talk about Abstract Factory. We'll show you why and when you'll want to use it, and what interesting little traps to watch out for. And that will start us on a lovely discussion about independent deployability, component design, jar files, type safety, type wars, smalltalk, Java, Eclipse, and No XML! Then we'll talk even more about the Factory Method and Prototype Patterns, and we'll discuss the problem of initialization. And we'll talk more about type safety, and language wars, and C vs. Pascal, and C++ vs. C, and Java vs. C++, and Smalltalk and Ruby, and NO NO NO XML!! Because we don't want to talk about XML. You heard me, right. NO XML! I don't want to hear about XML. I mean, for goodness sake, what were those guys thinking? XML was not a language that was designed for people to write! It was just a convenient syntax for a binary representation. You know, like X400, and X209, and ... What the bleeping bleep were those XSLT guys thinking. Or those ANT guys. And don't even get me started about Maven. Sheesh, angle brackets everywhere and I mean who the... It just makes me nuts that anybody would try to use XML for anything other than just looking at a data stream. I mean writing XML? WRITING XML???? That's just nuts, nuts, nuts. It's nuts I tell you. It's crazy kookie, wiered out nuts in the worm hole, and I don't know what to tell you these angle brackets are everywhere like little paperclips, like little spider legs, crawling, crawling up my spine and down my legs, and I just can't tolerate them all over me anymore and .....

At long last, the episode you've been waiting for. The episode on Strategy and Protocol. No. Protocol and Template Method. No. Uh. Strategy and Template Method. Yeah, that's it. S&TM! In this episode we are going to tear into the unimaginably powerful, wildly complicated, and ultimately impenetrable Strategy pattern! Applause!!! In this episode the secrets will be revealed. The mysteries will be solved. The arcanities will be explained. The unknowable will be made known. You, yes you!, will at last understand how to employ the Strategy pattern, and it's brother the Template Method pattern. We'll talk about the costs, the benefits, the uses, and the abuses of these patterns. It'll be cool. It'll be really cool. It'll be revolutionarily coooool! So come on, what are you waiting for? It's time to dive, head first into the maw of the beast and uncover the ultimate truths of: **Strategy and Template Method**

Come all without. Come all within. You've not seen nothing like the mighty FSM. This episode is all about Finite State Machines. What they are. Why and when to use them. How to represent them. And how to implement them. Including implementing them with The State Pattern. Yes, this is part of our series on Design Patterns. It's also the first in at least three parts that will lead us from the State pattern to the Visitor pattern. It's going to be an interesting journey. We begin it here by talking about state machines and how remarkably useful they are, and how frustrating they can be to implement. By the end of this episode we'll have decided that the solution to that frustration is to write a compiler that generates the code from a simple syntax. The next few episodes will explore how to write that compiler; and how to use Finite State Machines to write that compiler. These next few episodes are going to be fun, challenging, and important. You aren't going to want to miss them.

OK boys and girls, things are really starting to heat up. In this episode we start writing a compiler! Remember,that's what we said we were going to do. We said we'd write a compiler that generates finite state machines. Well, that's what were doing. And, boy, is it a hoot. We begin by exploring the syntax of our state machine language. That syntax begins as a simple state transition table, and then we add a few cute bells and whistles, like super states, entry, and exit actions, that make writing state machines a bit more convenient. Next we formalize our syntax by expressing it in Backus-Naur Form (BNF). Then we write a lexical analyzer to identify the terminal tokens of our syntax. Then we write a parser that identifies the grammar of those terminal tokens. And, ironically, that parser is a finite state machine! Then we use the Builder Pattern to write a builder that constructs the internal representation of our syntax. And if you don't think that's enough for one episode, you're crazy. So, put your propeller caps on and take a big swig of brain juice, because we're about to plow headlong into the heady topic of Writing the State Machine Compiler!

Where is Uncle Bob? He invited us over for dinner and we've been waiting and waiting. Where could he be? It's unlike him to be this late? Wait! What's that sound? Great Heavens! Who is that wretched creature at the door, guzzling our wine like a man bereft of his senses. Prepare yourself for an interesting journey. A journey through the land of Code Generation and The Visitor Pattern. In this episode we conclude the mini-series on the State Machine Compiler. In the last episode we had just finished the parser. In this episode we'll see the Semantic Analyzer, the Optimizer, the Generator, the Abstract Syntax Tree, and the code generating Visitors. And that means we've got a lot of code to look at. While we are looking it over, we'll take a short diversion into the rationale, and variations of the Visitor Pattern. And we'll also do a quick review of the Composite Pattern. We'll also see how the discipline of Test Driven Development differs in certain larger projects, from the small Katas and examples that we've seen in the past. So clear your head, and free your mind. Red pill or blue? It's up to you.

OK, get ready for some fun. In this episode we're going to dive deep into the Observer pattern. The first thing we'll do is derive the pattern from first principles. We'll begin with a simple real-time clock application and, step by step, apply one design principle after another until the Observer pattern emerges. Well, actually, what emerges is a structure that our current most popular languages can't implement, because it requires multiple inheritance. So we'll explore the workarounds to that, and then we'll rant about why Java and C# don't have this useful feature. The Observer pattern comes in two forms. The "Push" model, and the "Pull" model. We'll describe them both and discuss when and where each is appropriate. Then we'll turn to the larger pattern that the Observer fits into: Model View Controller. We'll look at the history of MVC, and the unfortunate corruption of the pattern by current web frameworks. Finally, we'll invoke the Humble Object pattern for testing GUIs, and we'll derive the Model View Presenter pattern from MVC.

OK, so now we're really starting the make progress through the design patterns. In this episode we'll study five of the most useful. First we'll discuss Singleton and Monostate; two patterns that help you enforce that only a single instance of a class is created. The real challenge with these patterns is how you initialize the static variables that are involved. So we'll walk through the whole nine yards of initialization issues, including threading issues, locking, double-checked locking, etc. You're going to love Monostate. It's a really cool pattern with lots of very interesting uses. Then we'll talk about nothing. Or rather, objects that do nothing -- or rather objects that get away with doing nothing by doing nothing in just the right way. The pattern is called: Null Object. Then, it's on to the Proxy pattern. This is the pattern used by most interprocess communication tools, and database isolation tools. Proxy is a pattern that is used when two objects need to communicate across a boundary, and should not know about that boundary. Lastly, we'll discuss the Decorator pattern. Decorator is a member of the Visitor family of patterns. It is another way to add new behaviors to existing class hierarchies without modifying those hierarchies. And after that we'll take a long deep breath to get read for the next episode -- and even more patterns.

This is the Patterns Roundup -- the Penultimate episode in our Design Pattern's series. In this episode you'll learn about five more patterns. Facade, Mediator, Memento, Flyweight, and Extension Object. The Facade and Mediator patterns are used when you have a group of objects that you want to impose a policy upon. Facade imposes that policy overtly from above. Mediator imposes it covertly from below. Memento is used when you want to capture the state of of an object inside an opaque token that can be passed around the system; and that can later be used to reconstitute the state of the captured object. Flyweight is used when you have a group of objects that share a large amount of common state. That state is moved into a separate object and shared amongst all the objects. Extension Object is yet another member of the Visitor family of patterns that allow us to add new behavior to existing hierarchies without changing those hierarchies.

This is the Pattern Apocalypse! The final episode about design patterns. And it's a doosy! In this episode we're going to talk about five patterns: Bridge Chain of Responsibility Interpreter Iterator Adapter You're going to love the discussion about the Bridge pattern. In it, I show you how to break down an subtype hierarchy with multiple degrees of freedom into a chain of several subtype hierarchies capturing one degree of freedom each. In the Chain of Responsibility discussion we extend those hierarchies so that clients have no idea what server is serving them. Then we explore Greenspun's 10th law by looking at the Interpreter pattern. And we learn that with great power comes great responsibility; and that most efforts to reduce programming workload by shifting it to the business simply cause that workload to bounce back to the programmers. You're going to find the Iterator discussion particularly interesting. It's not what you think it is. This discussion will teach you how to turn loops inside out so that the loops are at the bottom, being driven by the algorithm, instead of at the top and driving the algorithm. And then, at long last, the humble Adapter pattern. I'll go through a little history about comp.object discussions, and table lamps, and interface naming. And then we'll explore the two primary forms of the Adapter. So, if you're ready, it's time to dive in to the final set of Design Patterns. Fire up the Pattern Apocalypse!