Library

Course: From 0 to 1: Design Patterns - 24 That Matter - In Java

From 0 to 1: Design Patterns - 24 That Matter - In Java

  • Life Time Access
  • Certificate on Completion
  • Access on Android and iOS App
About this Course
  • Prerequisites: Basic understanding of Java
  • Taught by a Stanford-educated, ex-Googler, husband-wife team
  • More than 50 real-world examples

This is an intensely practical, deeply thoughtful, and quirky take on 24 Design Patterns that matter.

Let’s parse that.

  • The course is intensely practical, bursting with examples - the more important patterns have 3-6 examples each. More than 50 real-world Java examples in total
  • The course is deeply thoughtful, and it will coax and cajole you into thinking about the irreducible core of an idea - in the context of other patterns, overall programming idioms and evolution in usage
  • The course is also quirky. The examples are irreverent. Lots of little touches: repetition, zooming out so we remember the big picture, active learning with plenty of quizzes. There’s also a peppy soundtrack, and art - all shown by studies to improve cognition and recall
  • Lastly, the patterns matter because each of these 24 is a canonical solution to recurring problems

What's Covered:

  • Decorator, Factory, Abstract Factory, Strategy, Singleton, Adapter, Facade, Template, Iterator, MVC, Observer, Command, Composite, Builder, Chain of Responsibility, Memento, Visitor, State, Flyweight, Bridge, Mediator, Prototype, Proxy, Double-Checked Locking and Dependency Injection
  • The only GoF pattern not covered is the Interpreter pattern, which we felt was too specialized and too far from today’s programming idiom; instead we include an increasingly important non-GoF pattern, Dependency Injection
  • Examples: Java Filestreams, Reflection, XML specification of UIs, Database handlers, Comparators, Document Auto-summarization, Python Iterator classes, Tables and Charts, Threading, Media players, Lambda functions, Menus, Undo/Redo functionality, Animations, SQL Query Builders, Exception handling, Activity Logging, Immutability of Strings, Remote Method Invocation, Serializable and Cloneable, networking
  • Dependency Inversion, Demeter’s Law, the Open-Closed Principle, loose and tight coupling, the differences between frameworks, libraries and design patterns

Who is the target audience?

  • Yep! Engineers - from street-smart coders to wise architects - ought to take this course. After this class, you'll look at software design with a new pair of eyes
  • Yep! Product Managers ought to take this course - you will learn to understand the 'how' of Software Design without being constrained by it
  • Yep! Technology executives and investors who don't write code ought to take this course - after this you will always have an intelligent point-of-view on software, and won't find your eyes glazing over when its time to talk nitty-gritty
  • Computer Science majors (undergrad or grad) - if you are among the folks that make 'real world example Observer Pattern' such a common search phrase on Google, this is precisely the place for you
  • Yep! Journalists, Wall Street types or IP lawyers seeking to understand recurring patterns of problems and solutions in technology
  • Yep! If you are prepping hard for software engineering interviews :-)
  • Nope! This course is not right for you if you are looking for a Programming 101 course. That's not because there are pre-requisites, but simply because a Programming 101 course focuses on syntax, and on doing, while this course focuses on design, and on thinking
Basic knowledge
  • There are no pre-requisites other than curiosity - about Design, about Patterns, about Life :-)
What you will learn
  • Identify situations that call for the use of a Design Pattern
  • Understand each of 24 Design Patterns - when, how, why and why not to use them
  • Distill the principles that lie behind the Design Patterns, and apply these in coding and in life, whether or not a Design Pattern is needed
  • Spot programming idioms that are actually built on Design Patterns, but that are now hiding in plain sight
Curriculum
Lectures quantity: 63
Common duration: 11:44:50
What are Design Patterns?
  • What this course is about  

    We - the course instructors - start with introductions. We are a husband-wife team, studied at Stanford, and spent several years working in top tech companies, including Google, Flipkart and Microsoft.

    Next, we talk about the target audience for this course: Engineers and Product Managers, certainly, but also Tech Executives and Investors, or anyone who has some curiosity about technology.

    By the end of this class, students will be able to: spot situations where design patterns lead to better designs, and deploy those patterns effectively. Product managers and executives will learn enough of the 'how' to be able intelligently converse with their engineering counterparts, without being constrained by it.

    That's it for preliminaries - with this we plunge right in!

    • "Design Patterns are canonical solutions to recurring problems". We start by understanding what Design Patterns are, and why these patterns are still so popular decades after they were first put together.
    • Design Patterns, Libraries and Frameworks: A martial arts analogy illustrates the difference
    • Broad Categories of Patterns: We also take a quick swing through the major categories of Design Patterns - creational, structural and behavioral.


  • Creational, Behavioural and Structural Paradigms  

    Design patterns are often divided into three categories - creational, behavioural and structural. Let's understand what these categories represent.

  • Design Principle #1: Rely on Interfaces, not Implementations  

    'Program to interfaces, not implementations' said Eric Gamma. Of course he was right.

  • Design Principle #2: The Open/Closed Principle  

    Code should be open for extension but closed for modification. How can this be achieved? Well, there are 3 possible ways: inheritance, delegation, and composition.

  • Design Principle #3: Principle of Least Knowledge  

    Like children, code should only talk to friends, never to strangers!

  • Design Principles #4 and #5: Dependency Inversion and the Hollywood Principle  

    Always rely only on abstractions, never on details. Oh - and don't call us, we'll call you. That's how Hollywood works, and that's how the Hollywood Principle reads.

  • A taste of things to come  

    We will cover a fair bit of ground in this class. Here's a quick look at what's coming your way.

The Strategy Pattern
  • The Strategy Design Pattern: Introduction via String Sorting  

    The Strategy Design Pattern helps modify the behavior of classes at run-time - and does so using composition (member variables) rather than inheritance (parent classes). We examine how the Collections.sort method embodies the Strategy Pattern.

  • The Strategy Pattern and Dependency Injection - I  

    Dependency Injection is a widely-used design technique that is closely related to the Strategy Design Pattern. This lecture details how dependency injection is used to specify complex user interfaces in Java FX using an XML representation called FXML. This is a common technique used in modern UI frameworks in Java.

  • The Strategy Pattern and Dependency Injection - II  

    Dependency Injection is a widely-used design technique that is closely related to the Strategy Design Pattern. This lecture continues detailing the use of dependency injection to specify complex user interfaces in Java FX, and then ties back to the Strategy Design Pattern

The Decorator Pattern
  • The Decorator Design Pattern  

    The Decorator Design Pattern comes in handy when a class hierarchy needs to take into account multiple independent implementation details. One decorator class for each independent variable, each of which can be created from another. All decorator objects implement the same interface of course.

  • The Decorator Design Pattern In Action: Java File APIs  

    The Java File APIs are a classic use-case of the Decorator Pattern - it would be difficult to imagine an efficient way to implement these APIs without using the Decorator.

The Factory Pattern
  • The Factory Design Pattern: Introduction  

    Let's say your organization is moving from one database (say MS SQL-Server) to another (say Oracle). How would you use the Factory Pattern to minimize the effort needed for this enormous move?

  • The Factory Design Pattern In Action: Database Drivers  

    We continue with our planning for the move to Oracle from MS-SQL Server - we see how the Decorator Pattern, combined with the use of reflection and config files, can save us many late nights and bug bashes

  • The Abstract Factory Design Pattern  

    The Abstract Factory Pattern is closely related to the Factory Design Pattern, but is a better fit when entire different hierarchies of related objects need to be created. We also examine the Open-Closed Principle, which specifies that classes should open for extension but closed for modification.

  • The Abstract Factory Design Pattern: Families of classes  

    Let's see an example of how we can use the Abstract Factory pattern to create families of classes. We'll work with the same example of moving from Microsoft to Oracle as our database provider.

  • The Factory Design Pattern In Action: Reflection - I  

    These days, the Factory Design Pattern is increasingly implemented via Reflection, so it makes sense for us to understand the pros, cons, and complexities of Reflection

  • The Factory Design Pattern In Action: Reflection - II  

    As previously discussed, these days, the Factory Design Pattern is increasingly implemented via Reflection. In this video, we describe a specific use-case when Reflection is exactly the right tool for what we are seeking to accomplish.

The Singleton Pattern
  • The Singleton Design Pattern: Introduction  

    The Singleton Pattern is beautiful - a unique object, usually implemented via a private constructor and a static getter method.

  • The Singleton Design Pattern: Double-Checked Locking  

    The Singleton Pattern is very elegant in its construction, but there are important nuances that we should be aware of, specifically related to multi-threading and to class loaders in Java. In this lecture, we explore how a concurrency-related Design Pattern called Double-Checked Locking can come in handy while implementing the Singleton in a multi-threaded environment.

  • The Singleton Design Pattern: The Synchronized Keyword  

    The Singleton Pattern in a multi-threaded environment is surprisingly hard to get exactly right - we dig deeper into the subtleties - this requires us to understand the exact semantics of the Synchronized keyword.

  • The Singleton Design Pattern: Pulling together a multi-threaded solution  

    We tie together the different threads (bad pun!) we had going on multi-threading, and present a final thread-safe implementation.

The Adapter Pattern
  • The Adapter Design Pattern: Introduction  

    The Adapter Pattern is often used in converting data from one representation to another: we understand how an adapter can help with loose coupling of classes. Also, classes need not be rewritten to support additional interfaces, a new adapter is all that is needed.

  • The Adapter Design Pattern: Introduction - II  

    We continue with the benefits of adapters, and see a simple example of adapters - wrapping arrays so that all of the powerful functionality available for working with Collections can be easily applied to arrays too.

  • The Adapter Design Pattern In Action: Tables and Charts  

    The Adapter Pattern is simple: an adapter takes in an object (usually singular) of one interface, and gives back another object (also singular) of another interface.

The Facade Pattern
  • The Facade Design Pattern  

    The Facade Design Pattern hides in plain sight: complicated operations (such as networking and url handling) used to be incredibly onerous in C, and are incredibly simple in Java. We have the Facade Pattern to thank for this.

The Template Pattern
  • The Template Design Pattern: Introduction via Text Auto-Summarization  

    The Template Design Pattern is perfect when we need to specify a complex algorithm, and leave room for a client to plug in a specific implementation for a specific step. We examine this via an example from Natural Language Processing: automatically summarizing a document. We see how classic NLP algorithms can be plugged into the more general summarization algorithm via the Template Pattern

  • The Template Design Pattern In Action: Frameworks  

    The Template Pattern was the precursor to Frameworks - both embody the Dependency Inversion Principle, where high-level objects say to low-level objects "don't call us - we'll call you".

  • The Template Design Pattern In Action: Frameworks - II  

    The Template Pattern was the precursor to Frameworks - both embody the Dependency Inversion Principle, where high-level objects say to low-level objects "don't call us - we'll call you". We consider Java FX, a framework where the client plugs in code into a specific method, the framework does the rest (which is a lot!)

The Iterator Pattern
  • The Iterator Design Pattern: Introduction  

    The Iterator Design Pattern has become part of the daily idiom of programming; iterators offer a standard way to access elements in a collection, independent of the implementation of the collection.

  • The Iterator Design Pattern: Type Safety via Generics  

    We look at how generics help enforce type-safety in collections - and how iterators are correspondingly also generic.

  • The Iterator Design Pattern: Internal and External Iterators  

    We explore in further detail the differences between Internal and External Iterators, and also how the for-each operator has become a standard part of language support for iterators in Java, Python and other major languages

  • The Iterator Design Pattern: Language Support for Iterators in Python and Java  

    We continue look at how Python and Java have explicitly added language support for iterators, and also examine how iterators in Python are inextricably linked to the language (far more than in Java)

The MVC Paradigm
  • The Model View Controller Design Pattern: An Introduction  

    The Model-View-Controller (MVC) paradigm is ubiquitous in UI programming; along with the Observer and Command patterns, MVC has practically defined modern User-Interface programming.

  • The Model View Controller Design Pattern In Action: A MediaPlayer Example  

    Models contain data, views define the UI, and controllers respond to user input and update the model and the view. We see how this plays out in a Media Player application.

  • The Model View Controller Design Pattern In Action: A Chart Example  

    Models contain data, views define the UI, and controllers respond to user input and update the model and the view. We see how this plays out in a Charting application.

The Observer Pattern
  • The Observer Design Pattern: Introduction  

    The Observer Pattern, along with the MVC and Command Patterns, has practically defined modern UI programming. Publishers publish updates when their state changes, and Subscribers can listen in on these updates. An event is fired when the state changes, and the listener responds via a Command object called the event listener code.

  • The Observer Design Pattern In Action: Mouse Handling and Trees  

    After the relatively new-age Properties and Bindings, we turn to classic use-cases of the Observer Pattern, in User Interface elements such as mouse click handlers and tree views. The Observer Pattern is used in clever ways in Swing and other UI frameworks, allowing the user great flexibility in responding to a variety of different user actions.

  • The Observer Design Pattern In Action: MVC + Observer = UI Magic  

    We dig deep into the interplay between the Model-View-Controller and the Observer Pattern, tied together via the Command Pattern. These three patterns have, together, defined modern User-Interface programming

  • The Observer Design Pattern In Action: A MediaPlayer Example - I  

    Models contain data, views define the UI, and controllers respond to user input and update the model and the view. We see how the Observer Pattern plays a crucial role in seting up this MVC example for success - for instance, a slider that wires up the volume of the media is just about 1 line to set up correctly.

The Command Pattern
  • The Command Design Pattern: Introduction  

    The Command Design Pattern is used to separate an action from its execution. A seemingly abstract idea, and an incredibly powerful one. The Command Pattern, along with the Observer and MVC Patterns, has practically defined modern User Interface Programming.

  • The Command Design Pattern In Action: Lambda Functions - I  

    The idea of encapsulating an action in an object can be used to retro-fit functional programming support into an object-oriented language like Java. Lambda functions, in particular, are a functional programming concept that has become a cross-over hit in the object-oriented world of Java.

  • The Command Design Pattern In Action: Lambda Functions - II  

    We continue with functional-programming support in Java. In addition to lambda functions, there are also powerful aggregate operators - map, foreach and filter - that we can use to chain lambda functions together

  • The Command Design Pattern In Action: Threading  

    The Command Design Pattern is used to separate an action from its execution. We see how this idea is used as the starting point of most modern Threading libraries. Java has old-school and new ways of getting Multi-threading done, and both of these start with the Command Pattern.

  • The Command Design Pattern In Action: Undo and Logging  

    The Command Design Pattern is used to separate an action from its execution. This idea serves as the basis of two really neat applications: implementing Undo, and logging activity. Let's see how.

The Composite Pattern
  • The Composite Design Pattern: Introduction via Decorators  

    The Composite Pattern works best when a tree-shaped class hierarchy needs to be set up; This is understood best via the Decorator Pattern, which in turn works best when an onion-like class hierarchy (similar objects wrapped inside each other) works best. So we start with a segue into the Decorator Pattern, specifically with the objective of making the Composite clear via juxtaposition.

  • The Composite Design Pattern: Class Hierarchy  

    We finally get to the Composite Class Hierachy, and study the tree-shaped class structure it usually results in.

  • The Composite Design Pattern In Action: Transitions, Swing Containers  

    Two canonical examples of the Composite Pattern: Swing UI containers, and Transitions in Java FX. Swing containers (JPanels) contain other containers, leading to a tree-like object structure. Likewise, in Java FX, two special types of transitions - parallel and sequential transitions - contain other transitions, leading to a nested object hierarchy.

The Builder Pattern
  • The Builder Design Pattern: Introduction  

    The Builder Pattern works best when a complicated object needs to be set up, with inputs in its construction flowing in over time (because this information is not all available when the object is constructed, the Builder pattern usually is marked by constructors that do little, if anything). We start with a simple example, of an HTML Builder.

  • The Builder Design Pattern In Action: An SQL Query Builder I  

    A more substantial example of the Builder Pattern, this time put to use to build SQL queries. This is a classic and canonical example of the Builder Pattern.

  • The Builder Design Pattern In Action: An SQL Query Builder II  

    We continue with our use of the Builder Pattern to build SQL queries. This is a classic and canonical example of the Builder Pattern. In this lecture, we show the Builder Pattern would work in this case, and how it would solve the issues we encountered with our previous approaches.

The Chain of Responsibility Pattern
  • The Chain of Responsibility Design Pattern  

    The Chain of Responsibility Design Pattern makes sense when any one of many objects might know how best to deal with a situation, but its not clear in advance which object exactly that will be. The 'event' then gets passed around in order, and the first object that knows what to do handles the event. This is exactly how Exception handling works in most languages, including Java.

The Memento Pattern
  • The Memento Design Pattern  

    The Memento Design Pattern makes sense when objects need to know how to save their state, and know how to revert to that state.

  • The Memento Design Pattern : Serialization  

    The usual way of implementing the Memento pattern is via Serialization - this used to be very onerous, but modern languages provide support that make Serialization quite simple.

The Visitor Pattern
  • The Visitor Design Pattern  

    The Visitor Design Pattern is inextricably linked to the Composite: Composite Design Patterns usually result in class hierarchies that look like trees, and a Visitor Object knows how to perform operations on each node of the tree.

The State Pattern
  • The State Design Pattern  

    The State Design Pattern is specifically meant for objects that need to maintain an internal State Machine. This pattern is a super-neat trick that allows the state transitions, as well as the the addition of new states, surprisingly easy.

  • The State Design Pattern in Action : Mediaplayer  

    A deeper look at the State Pattern taking the example of implementing states for a mediaplayer

The Flyweight Pattern
  • The Flyweight Design Pattern  

    The Flyweight Design Pattern is used when we would like only 1 distinct object per distinct value of an underlying variable. This usually results in immutable objects - most famously like Strings in Java.

  • The Flyweight Design Pattern : Multithreading  

    This class talks about the complications involved when using flyweights with multi-threading. If you ever implement the Flyweight Pattern, be sure to understand the .equals() method, and to override it.

The Bridge Pattern
  • The Bridge Design Pattern  

    Class Hierarchy Explosion? If you find your class hierarchy getting too complicated to understand, consider the Bridge Pattern, which splits a complex hierarchy into multiple, far simpler hierarchies, and then uses Composition (member variables) to stitch these hierarchies together.

The Mediator Pattern
  • The Mediator Design Pattern  

    The Mediator Design Pattern is awesome when a class hierarchy is complicated to implement, but conceptually very simple to use. Similar conceptually to the Facade Pattern, but the Mediator makes sense when there are a number of peer objects - the class hierarchy looks like the hub-and-spoke structure in a wheel.

The Prototype Pattern
  • The Prototype Design Pattern  

    The Prototype Design Pattern makes sense when an object needs to be able to clone itself. This is related to the idea of copy constructors - but with the twist that in Java, this relates to an interface called Cloneable. Cloneable is a poorly designed interface - this class will also explore why.

The Proxy Pattern
  • The Proxy Design Pattern  

    The Proxy Design Pattern makes sense when one object must stand in for another. The canonical example is Remote Method Invocation, which is built entirely on the Proxy Pattern, and which for years was the easiest way to write a distributed computing application. RMI has now been rendered obsolete by more modern distributed computing techniques such as Rest APIs, but the Proxy Pattern made this big leap possible.

Reviews (0)