On The Road To Professional Web Development | Design Patterns

*The objective of this article is to prepare for a technical interview. To succeed (1) we must be technically proficient, and (2) we must be capable of communicating our proficiency effectively.

In this post, we’ll first become conversationally fluent on the topic. Next we’ll study a reliable guide summarizing popular design patterns. Finally we’ll finish the discussion with a curated list of (reportedly) common interview questions.

This post is part of a series on becoming a professional web developer — click here to navigate to the table of contents*

Part I: Design Patterns

How Difficult Is It To Master?

Design patterns at their core are just a set of well known software engineering best practices. To use or avoid applicable design pattern when authoring software is a delicate matter. We want to be professional software developers, which means we should strive for quality and professionalism in our code. Consistency and simplicity are what we strive for — design patterns are only a small subset of ideas that help us meet these objectives. This brings us to an interesting point — just because we’ve found places in our code that we can use design patterns, it doesn’t necessarily mean we should. We want our intentions to be clearly expressed in code — but it’s easy to get caught up trying to enforce unnecessary conventions. Understanding how to strike this delicate balance comes from a combination of experience over time and learning to communicate and refine design considerations with your team.

Design Patterns: What Are They?

Design patterns can be the friend or foe of developers. They are a non-exhaustive list of well-known techniques, learned by trial-and-error and shared across large communities of developers over the years. They are really just a formalized set of engineering best-practices. There may be obvious instances where specific design patterns apply to our situations, but overusing them can be just as bad as not using them at all. If we want other people to be able to understand and contribute to our code, we must evaluate every design decision we make through this lens — including the decision to use (or not to use) specific design patterns.

What Terminology Comes Up When Discussing Design Patterns?

• Behavioral Design Patterns: a category of design patterns. “On inter-object communication”
• Concurrency Design Patterns: a category of design patterns. “On multithreading”
• Creational Design Patterns: a category of design patterns. “On object instantiation”
• Dependency Inversion Principle: a SOLID design principle. “Depend on abstractions, not concretions”
• Design Pattern: well-known software engineering best-practices. “This resource lists more than we’ve discussed in this post, including a set of design patterns known as concurrency patterns”
• Gang of Four (GoF): the four authors responsible for the famous 1994 Design Patterns textbook. “Wikipedia provides a great synopsis of the concepts presented in their book”
• General Responsibility Assignment Software Patterns (GRASP): guidelines for OOP. “more on this here”
• Interface Segregation Principle: a SOLID design principle. “Many interfaces with narrow scope are better than one with wide scope”
• Liskov Substitution Principle: a SOLID design principle. “Objects should be replaceable with instances of their subtypes”
• Open-Closed Principle: a SOLID design principle. “Software should be open for extension but closed for modification”
• Single-Responsibility Principle: a SOLID design principle. “Classes should have a single responsibility”
• SOLID: a mnemonic acronym. “SOLID design principles exist to improve the quality of any software design”
• Structural Design Patterns: a category of design patterns. “On object internals”
• The Abstract Factory Design Pattern: a creational design pattern. “Group related factories”
• The Adapter Design Pattern: a structural design pattern. “A compatibility band-aid”
• The Bridge Design Pattern: a structural design pattern. “Prefer composition over inheritance”
• The Builder Design Pattern: a creational design pattern. “Avoid telescoping constructors”
• The Chain of Responsibility Design Pattern: a behavioral design pattern. “Try these things in order until one of them works”
• The Command Design Pattern: a behavioral design pattern. “Encapsulate all information needed to perform an action or trigger an event at a later time”
• The Composite Design Pattern: a structural design pattern. “Treat instances the same as collections of instances”
• The Decorator Design Pattern: a structural design pattern. “A wrapper”
• The Facade Design Pattern: a structural design pattern. “Provide a simplified interface to complex code”
• The Factory Method Design Pattern: a creational design pattern. “Delegate instantiation logic to child classes”
• The Flyweight Design Pattern: a structural design pattern. “Recycle similar data for memory efficiency”
• The Iterator Design Pattern: a behavioral design pattern. “Access elements without exposing the underlying presentation”
• The Mediator Design Pattern: a behavioral design pattern. “Encapsulate object interactions”
• The Memento Design Pattern: a behavioral design pattern. “Rollback state”
• The Observer Design Pattern: a behavioral design pattern. “Push notifications”
• The Prototype Design Pattern: a creational design pattern. “Instantiate an object through cloning”
• The Proxy Design Pattern: a structural design pattern. “Represent the functionality of another class”
• The Simple Factory Design Pattern: a creational design pattern. “Create an instance without exposing detailed requirements for construction”
• The Singleton Design Pattern: a creational design pattern. “Ensure one class results in only one instance of that class”
• The State Design Pattern: a behavioral design pattern. “Change class behavior according to state”
• The Strategy Design Pattern: a behavioral design pattern. “Select implementation based on the situation”
• The Template Method Design Pattern: a behavioral design pattern. “Define the program skeleton of an algorithm”
• The Visitor Design Pattern: a behavioral design pattern. “Add new operations to existing object structures without modifying those structures”

Part II: Using Design Patterns

Part II focuses on understanding the role of design patterns. This is a subject of continued debate — and hopefully we all come away from this discussion with the understanding that this is the way it should be. Design patterns aren’t universally ‘good’ or ‘bad’. We need to evaluate these (and all other) design decisions on their merits relative to the problem at hand, and we should be able to formulate and defend our own opinions while remaining open to debate and constructive criticism.

• Read this article on levels of developer seniority. (I see this as being the fundamental philosophy that primarily motivates whether or not we should apply eligible design patterns to our work)
• Read this summary description on design patterns by kamranahmedse. (his work inspired the current post — we’re exploring design patterns per his recommendation. I can’t think of a better opportunity to understand exactly what he meant than to read his own post on the topic)

Part III: Design Pattern Interview Questions

• discuss behavioral design patterns
• discuss creational design patterns
• discuss design patterns
• discuss structural design patterns
• discuss the Abstract Factory design pattern
• discuss the Adapter design pattern
• discuss the Bridge design pattern
• discuss the Builder design pattern
• discuss the Chain of Responsibility design pattern
• discuss the Command design pattern
• discuss the Composite design pattern
• discuss the Decorator design pattern
• discuss the Facade design pattern
• discuss the Factory Method design pattern
• discuss the Flyweight design pattern
• discuss the Gang of Four
• discuss the Iterator design pattern
• discuss the Mediator design pattern
• discuss the Memento design pattern
• discuss the Observer design pattern
• discuss the Prototype design pattern
• discuss the Proxy design pattern
• discuss the Simple Factory design pattern
• discuss the Singleton design pattern
• discuss SOLID design principles
• discuss the State design pattern
• discuss the Strategy design pattern
• discuss the Template Method design pattern
• discuss the Visitor design pattern
• list 10 behavioral design patterns
• list 6 creational design patterns
• list 7 structural design patterns

Closing Thoughts

I hope you’ve enjoyed this post as much as I enjoyed writing it. If you have thoughts you’d like to share, your editorial suggestions are always welcome. This post is part of a series on becoming a professional web developer. If you’d like to see more content like this, please click here to navigate to the table of contents.