Java Design Patterns

Like so many programmers of my generation, I started coding in BASIC. After a short foray into Turbo Pascal, my university led me gently to C.

Professor MacGregor then introduced C++. His lectures were ramblings in a thick Glasgow accent with matching handwriting. Stroustrup's writing became my bible.

All through my university education, I struggled to rid myself of the bad habits endowed by years of BASIC and C. Polymorphism? No, I used switch statements and multi-conditional ifs.

I was insanely productive through the generous application of CTRL+C and CTRL+V. Part of my masters was an editor for SDL, used for network protocols. My professor and I sold this to a company in France. They visited us at the University of Cape Town and liked my program. To make it perfect, they wanted a few changes. It only took me a few hours to finish everything they wanted.

IT WAS ONLY WHEN I STARTED WORKING THAT I DISCOVERED THAT EVERYTHING I HAD LEARNED ABOUT OBJECT-ORIENTATION WAS WRONG

I had used the same coding techniques from C and BASIC in my C++ code. The result were lots of switch statements distributed throughout my codebase. Whenever I had to add a new design element, I would have to find and change each switch statement in turn. If I forgot one, which happened a lot, then one feature would not work anymore. For example, if I didn't change the switch for printing, then my new element would show on the screen, but not in the printout. Each time I added one element, I had to test each function in turn to make sure everything worked.

This type of coding behaviour might be ok when you're the only one working on that code. But it doesn't make for happy team mates.

At my first real job, my mentor handed me the GoF book and said: "Here, you have to read this."

I did. Most of the patterns seemed somewhat familiar from my years of coding C++. I put it aside. What could I possibly learn?

A year later I heard Martin Fowler at a conference in Cape Town. He described "Design Patterns" as the most significant software development book of the decade.

I picked it up for a second read. Perhaps I had missed something? It all seemed obvious the first time.

I DID NOT UNDERSTAND A WORD ON THE SECOND READ

How was it possible that a year of coding experience had made me so stupid? Surely real-world coding should have the opposite effect, making me more valuable as a programmer?

Indeed, it had. But the first time I read the book, I did not have enough insight to understand its true value. Martin Fowler's words had made me pick up the book for a second time that I had discarded as "completely obvious".

I struggled through each pattern, trying to think of places where I had seen it in our Java project. We even formed a design pattern study group that met every Friday lunch. I still remember the Visitor pattern described by my colleague Martin Booyens. He spoke about the dominee (Afrikaans for parson) visiting. Whilst I remember his analogy twenty years later, I was complete befuddled by his explanation of this rather simple pattern. Having lay people teach the patterns did not work as well as we had hoped.

TEACHING DESIGN PATTERNS IS HARD - MANY ONLINE PATTERNS COURSES HAVE SERIOUS ERRORS THAT WILL HURT YOU

During my third read through GoF, I finally had the Eureka! moment. Every pattern used polymorphism. Even the Singleton. This was the key concept used everywhere. Furthermore, most of the pattern used a combination of inheritance and composition. When in doubt, we used composition.

If only I had known all this during my university days, I could have avoided all those nasty switch statements.

I immersed myself in patterns, determined to understand the various nuances of each design. I bought books, read papers, reached out to one of the authors of the original GoF book - John Vlissides. I even did a technical review on some papers he authored for IBM (Composite1 and Composite2). I studied the writing of Christopher Alexander, famous architect whose pattern language the software community cloned. After months of preparation, I was ready to teach my first Java design patterns course.

BOOKS REFERENCED IN THIS COURSE

There are others. I own about 30 books on patterns. I read them so that you don't have to. But these are the most important. Especially Pattern Hatching. If you buy any one book, get that one.

SOMETHING INTERESTING HAPPENED

Something interesting happened. I would teach a small class at a company. A few months later, I would get an order for a much larger course. This often carried on until the entire development staff had gone through the course.

Why was this? Why did companies want everyone to learn this?

Ordinary Java courses and university curricula focus on the syntax of the language, but are sparse on the semantics. If they are lucky, students will learn that there are three different types of patterns: creational, behavioral and structural. But they won't see the practical applications of where patterns are used.

In my Java Design Patterns Course, I show where each of the patterns is used in the Java Development Kit. This makes our course immensely practical. The patterns are not just some abstract concepts. They are presented from the coal face of timeless software.

DESIGN PATTERNS ARE RELEVANT TODAY

Through its 18 year history, and with countless revisions, our Design Patterns Course has remained relevant and useful. The patterns of Iterator, Composite and Strategy are as important with Java 11 as they were with Java 1.1. As in the 90s, patterns still make programmers more productive and able to communicate better.

Java 8 added lambdas and method references to the language. This makes some patterns such as Command easier to use. Default methods in interfaces means we are not always force d to use abstract classes.

No one likes forward references in books or courses. "Don't worry about this, we will do it in a later chapter" tends to distract us. We try to have as few of these as possible.

We start with an extensive introduction to Java on modern virtual machines. A lot of the concerns in the original Gang-of-Four book stem from when we only had static compilation. Java can optimize our code on-the-fly. The JIT compiler can even inline polymorphic method calls, if it can determine that it is safe. If later on another type of subclass appears, it will undo that optimization. Indirection costs are also inlined. Too many objects? No worries, the garbage collector does a splendid job of managing these.

One of the starting precepts is that of meronomy. This defines what we mean by "part-whole hierarchy". The reason we care about meronomy is because we need to avoid memory leaks in our designs. Memory leaks should be a thing of the past with Java's automatic memory management. Unfortunately they still happen when we ignore meronomy.

Another important concept is intrinsic versus extrinsic state. It occurs in lots of the patterns. We can usually rewrite the implementations to move from one to the other. Neither is good or bad, but extrinsic usually allows us to share objects. Intrinsic is a bit more object-orientated.

THE GOLDEN ORDER

After our detailed introduction, we start with simple patterns that occur everywhere. Patterns like Strategy, Iterator, Proxy and Abstract Class.

Most courses and books starts with the creational patterns Singleton and Factory Method. The thinking is that these are very simple patterns. They are not. Singleton has a lot of subtleties. The pattern allows polymorphism and multiple instances of the "Singleton". Lazy vs eager initialization? Most courses get this wrong, with code that can break in production.

The patterns are sourced from both the original Gang-of-Four book by Erich Gamma et al, in addition to proceedings from the Pattern Language of Program Design conferences. They are categorized into behavioral (B), structural (S) and creational (C) patterns. Here is the golden order that we follow through this maze of patterns:

Abstract Class (B), Builder (C), Essence (C), Memento (B), Proxy (S), Flyweight (S), Strategy (B), Null Object (B), Iterator (B), Factory Method (C), Template Method (B), Composite (S), Visitor (B), Acyclic Visitor (B), Object Recursion (B), Default Visitor (B), Adapter (S), Command (B), Decorator (S), Extension Object (S), Singleton (C), State (B), Facade (S), Prototype (C), Abstract Factory (C), Interpreter (B), Mediator (B), Observer (B), Bridge (S), Chain of Responsibility (B)

EXERCISES, EXERCISES, EXERCISES, EXERCISES, EXERCISES

We learn more by doing than by listening. Every pattern is followed by exercises that we solve to improve our understanding of the pattern. For each exercise we have model solutions and a detailed walkthrough, where I show you the thought process in solving the exercise. Some of the exercises are hard. Others easier.

We have different types of exercises for the patterns:

COURSE COMPLETION CERTIFICATE

So your employer bought this nice shiny course for you. How can you prove to them that you have finished it?

Teachable tracks your progress through the course. At the end of each section, you can mark it as "completed". Once you have finished at least 88% of the course, you can qualify for a course completion certificate. To claim this, you can submit your completed exercises to Heinz Kabutz for marking. The certificate and marking cost are included in your course price.

UNHAPPY? GRAB A 100% REFUND WITHIN 30 DAYS!

We believe that this is the best value-for-money course in the Java world. It is useful for all levels of Java knowledge: beginner, intermediate and advanced. Everyone will learn something that will help them become better Java programmers.

To put our money where our mouth is, we are offering a 100% money-back guarantee within 30 days of purchasing the course. No questions asked. Simply let us know that this training wasn't for you and we will refund you.