Here is a book that takes the sting out of learningobject-oriented design patterns! Using vignettes from the fictionalworld of Harry Potter, author Avinash C. Kak provides a refreshingalternative to the typically abstract and dry object-orienteddesign literature.
Designing with Objects is unique. It explains designpatterns using the short-story medium instead of sterile examples.It is the third volume in a trilogy by Avinash C. Kak, followingProgramming with Objects (Wiley, 2003) and Scripting with Objects(Wiley, 2008). Designing with Objects confronts howdifficult it is for students to learn complex patterns based onconventional scenarios that they may not be able to relate to. Incontrast, it shows that stories from the fictional world of HarryPotter provide highly relatable and engaging models. Afterexplaining core notions in a pattern and its typical use inreal-world applications, each chapter shows how a pattern can bemapped to a Harry Potter story. The next step is an explanation ofthe pattern through its Java implementation. The following patternsappear in three sections: Abstract Factory, Builder, FactoryMethod, Prototype, and Singleton; Adapter, Bridge, Composite,Decorator, Facade, Flyweight, and Proxy; and the Chain ofResponsibility, Command, Interpreter, Iterator, Mediator, Memento,Observer, State, Strategy, Template Method, and Visitor. Forreaders' use, Java code for each pattern is included in thebook's companion website.
* All code examples in the book are available for download on acompanion website with resources for readers and instructors.
* A refreshing alternative to the abstract and dry explanationsof the object-oriented design patterns in much of the existingliterature on the subject.
* In 24 chapters, Designing with Objects explains well-knowndesign patterns by relating them to stories from the fictionalHarry Potter series
Avinash C. Kak is Professor of Electrical and ComputerEngineering at Purdue University. His areas of interest includesoftware engineering, computer and network security, sensornetworks, and computer vision (especially with camera networks).Professor Kak has been awarded numerous Best Teacher of the Yearawards at Purdue University. He is the author of Scriptingwith Objects and Programming with Objects,both published by Wiley.
Readers who have been following the progress of my Objects Trilogy project will be pleased to see this third and final book of the Trilogy - even if it is almost two years behind schedule.
As to the cause for the delay, the primary culprit was finding the right medium for explaining the design patterns. When I first announced my Objects Trilogy project several years back, my plan, as stated then, was to explain the patterns through famous short stories of the world. By famous I meant classic and universal - the sort that would not need to be re-told when used for explaining the patterns. These would be the stories by Hans Christian Anderson, the Brothers Grimm, and their counterparts from around the world. But, unfortunately, when I started mapping the patterns onto the stories, it became increasingly clear that such stories did not possess the level of complexity that was needed for the patterns. That's when I turned to Harry Potter.
I should also mention that, at the beginning of this book project, Harry Potter was the farthest thing from my mind. Not that I was unaware of the worldwide phenomenon that Harry Potter had become. After all, who could have missed media reports like the mile-long lines of kids and parents waiting for the stores to open with the release of each new Harry Potter book. But to me, having grown up with time-honored and celebrated short stories of the sort mentioned above, it seemed unnecessary to have to wade though a very long story (seven books) in order to explore its possibilities for explaining the design patterns.
However, after realizing the limitations of traditional folklore and fairy tales for this project, I turned to Harry Potter with a greater seriousness of purpose. As I started reading the series, I was completely blown away not only by the story-telling powers of J. K. Rowling, but also by the delightful complexity of the subnarratives within the overall multi-volume story. As I wended my way though successive Harry Potter books, every once in a while I'd have an "Aha!" moment when I encountered a segment of the story that appeared to have the complexity I was looking for.1 Despite numerous such moments, it still took multiple readings of the series - besides conversations with family and friends and, especially, the children of family and friends who had devoured Harry Potter many times over - before I had any confidence in using a particular part of the story for explaining a pattern.
I would not be surprised if the initial reaction of a reader to my use of Harry Potter for explaining the patterns would be something like: "Where is the need for using a literary medium of any sort for such explanations?" Such readers are likely to add: "If the current explanations of the patterns are not satisfactory, why not base any further explanations on real-world examples as opposed to stories from a magical world?" I am going to address these questions next.
In addition to the seminal book "Design Patterns - Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides that first introduced the patterns to the programming world, there now exist virtually hundreds of explanations of these patterns in various books and on the internet. I maintain that the large quantity of this material has not made it any easier to understand many of the more difficult patterns. Rather, the more difficult patterns continue to be as opaque today as they were at the time of their first presentation by Gamma et al. And the fact that they were quite difficult to understand even through the original explanations provided by Gamma et al. can be inferred from the following comment in the Preface of their book: "A word of warning and encouragement: Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing!"
Let me now address the issue of using real-world examples to improve upon the current stock of explanations of the patterns. Note that for a large majority of the explanations that are currently out there, the authors have indeed tried to use real-world examples. But these explanations do not work well for various reasons. The main reason, probably, is that the typical space constraints prevent the authors from fully presenting a real-world application.2 As such, what a reader gets is a highly abbreviated version of some realworld example that is often difficult to appreciate from the standpoint of its relevance to the pattern. Additionally, a reader may have zero interest in the real-world application being used by an author. If for whatever reason a reader cannot connect with the so-called realworld examples, why not use examples from a familiar literary work in the hope that the reader would find those easier to relate to.
Based on my own experience with the teaching of object-oriented (OO) design patterns, I have observed that when a student tries to grasp the software abstraction in a pattern through an instructor's highly abbreviated presentation of some real-world application that fails to motivate, what you get is an immediate disconnect between the student and the instructor. And if it should happen that a pattern explanation is based on an application that the instructor is not familiar with, the student is likely to receive a presentation that lacks clarity and conviction.
I believe it's due to a lack of any explanatory material that can hold the attention of the students and that, at the same time, lends itself to teaching without placing a large burden on the instructors that the OO patterns, despite their great importance, are taught mostly in a piecemeal fashion. In most cases, a software engineering instructor teaches just a half dozen patterns that he/she is comfortable with. It's rarely the case that all of the patterns are taught in any concerted fashion.
I must emphasize that not all patterns are difficult to understand. In fact, several that deal with object creation are downright easy and can be comprehended immediately with the simplest of explanations. But those patterns that involve fairly complex run-time interactions between different objects can require significant effort before they begin to sink in. It is these more complex patterns that Gamma et al. were surely referring to in the quote from their preface that I showed earlier. The goal of my book is to make it easier to understand these patterns in particular with the help of stories drawn from Harry Potter.
It is possible that some of you are thinking that Harry Potter is already passé - since it is not as constantly in the news as it used to be - so I might be hitching my wagon to a fading star for explaining the patterns. Yes, it does appear that the extremely intense media hype that surrounded Harry Potter for several years has passed. But that's because nothing lasts forever in the media, and that applies as much to themes that are merely ephemeral as it does to themes that are timeless. I still see a lot of young people reading and enjoying Harry Potter. My sense is that Harry Potter is as timeless as, say, Dr. Seuss. Neither receives much media attention any longer, but both continue to be widely enjoyed around the world.
I am obviously under no illusion that all readers who have had difficulty understanding the more complex patterns with the currently available crop of explanations will suddenly have "Aha!" moments when they read my Harry Potter-based explanations for the same. I am also reasonably certain I'll be at the receiving end of brickbats for melding the serious subject of OO design with the airy material of Harry Potter. Nonetheless, at the very least, this book will demonstrate that it is possible to construct explanatory analogies for OO design patterns using themes that we resonate to emotionally (through our fantasies or otherwise). Even if this book only encouraged other authors to write books in the future that use unconventional analogies - analogies that we can relate to on the basis of our shared human experiences - for explaining ideas that are generally considered to be complex and dry, I'd be satisfied.
That brings me to the subject of the Harry Potter stories I have used in this book. If you have read the series, you probably have your own favorite stories. As to what those might be is likely to depend on several factors, including possibly your educational background and cultural perspectives. However, if you are of a scientific bent of mind, it is difficult for me to imagine that the stories related to the following magical objects did not leave indelible impressions on your mind: the Sorting Hat for placing each year's fresh crop of admittees in the four Hogwarts houses; the Remembrall as a memory aid; the Time-Turner for time travel; the Howlers for conveying emotions in the strongest possible sense; the Floo network for quick travel around London; the Death Mark for instantaneous signaling; and several others. What these stories convey is not too far from our own fantasies that are borne partly of our scientific exuberance and partly from our desires to cope with everyday life and all its frustrations. I have used several of these stories in the explanations of the patterns in this book.
With regard to the organization of the book, it consists of three parts: the first is devoted to Creational Patterns, the second to Structural Patterns, and the last to Behavioral Patterns. Within each part, each chapter is devoted to a...