Day 17 of 100 The Lessons of Design Patterns

June 1, 2013 — Posted by Al Shalloway

Continuing with the 100 Things You Must Know to Be Effective In Software Development

Years ago people knew they didn't know much about design patterns.  Now, most folks think they know design patterns, but my experience in talking to them makes me believe otherwise.  Sorry if this sounds a bit aloof, arrogant or elitist, but I do believe it is true.  Patterns have been called "solutions to recurring problems in a context" by Christopher Alexander in his Timeless Way of Building (one of my all-time favorite books that I highly recommend, whether you want to learn patterns or just learn more about architecture). While this phrase is bandied about quite a lot, what's not as well know is another quote from the book: "at this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real."  Alexander is referring to the forces in the problem domain - that is, the issues you must attend to to achieve a high quality design.

The Gang of Four book, Design Patterns: Elements of Reusable Object-Oriented Software actually provides these forces, but if one is looking for solutions, they are often overlooked.  While getting into a discussion of how patterns teaches us about forces would be beyond the scope of this blog (see references at the end of this blog for that), we can talk about how design patterns provide us with a solid approach to design - one that is often overlooked.  Chapter 1 (Introduction) from the book provides an overview of the lessons learned from Design Patterns:

  • design to interfaces - that is, design to the behavior of the object, not it's implementation.
  • find what varies and encapsulate it (essentially, put a layer in, either with an Interface, Abstract class, or even an object that figures out the proper delegation
  • favor delegation over inheritance. In other words, instead of having different ways of doing things by deriving new methods in a class that uses these methods (which leads to a complex inheritance hierarchies), have objects that are hidden behind interfaces and have the using object refer to this interface

Basically, patterns tell us to hide variation in our solutions and do it by encapsulating the implementations that vary behind Interfaces, abstract classes, function pointers, or any way you can think of.  You can quickly see most of the patterns are examples of this by looking at our list of Patterns by Encapsulation on our Design Patterns Repository.  You'll notice all of the behavioral patterns are about this. To accomplish this requires separating use from construction.  This is essentially the practice of encapsulating construction so that objects don't know which particular implementation of a behavior they are using.  You either make an object or use an object, but not both.  Patterns that do this are the creational patterns.

But what do you use when you already have objects and want to put them into this encapsulating scheme?  That's where the structural patterns come in.

I do strongly suggest you delve more in here in some way or another.  While knowing a few patterns (e.g., strategy, template method, bridge, ...) is great, understanding what they truly are and how to think in terms of the forces they expose is much more powerful.

Want more?  Check out:

As always, please let me know if you'd like to chat about opportunities.

Al Shalloway
CEO, Net Objectives

A note on the 100 in 100 challenge: I will pick up the daily entries this week.  To be able to accommodate this with my existing schedule, I will start writing short blogs that point to other materials when available.  The intent will shift to awareness instead of trying to explain the concept. This should make it both easier for both author (me) and reader (you) to keep up.

If you liked this blog please tweet about it by clicking the icon below.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban