Collecting Design Patterns

Today we expect every professional Software Engineer to have a good knowledge of Design Patterns. In particular, the names of the patterns in the Gang-of-Four (GoF) book became part of the common vocabulary of software developers. Any good programmer should know the meaning of a Visitor, Singleton or Strategy.

These patterns are part of the general knowledge shared by most professionals in the software industry, independently of the specific fields they are working on. People implementing systems as diverse as games, banking and telecommunications can still apply the same patterns. The GoF Design Patterns widespread usefulness is derived from their generic and abstract properties.

However, to be able to perform our jobs effectively, besides generic knowledge we also need domain-specific knowledge. People developing games have to solve some particular problems that are different from the ones in banking and telecommunications applications. With time, the experts in games programming will have acquired valuable knowledge about how to approach the challenges specific to their field.

Imagine a professional has two set of tools:

  • The first set has the common tools used by all other people in the same profession. These are multi-purpose tools that you can buy at any store and are easy to find.
  • The second set has very specialized tools that the professional himself has invented. The creation of these tools was the result of many years of experience solving some very specific kinds of problems.

Of course other professionals could benefit from this second set of tools. But then you need ways to share these tools with them.

In the case of software development, we are very good at applying the generic and abstract design patterns. But we still need better methodologies to:

  • Identify design patterns specific to our problem domain.
  • Classify domain-specific patterns according to their purpose.
  • Document domain-specific patterns so that they can be easily understood.
  • Collect domain-specific patterns in a repository so that they can be easily shared.

I think that every software development organization should invest resources to create its own collection of design patterns. Every developer in the organization should be aware that he is expected to identify new patterns, classify and document them, and then add them to the shared repository.

I believe that the benefits for the organization are clear. They include:

  • Sharing and preserving knowledge in an effective format.
  • Creating a common vocabulary.
  • Helping new developers learn about the domain.
  • Increasing developer productivity by providing reusable solutions.
  • Improving software quality by using solutions that were already tested.

So good luck collecting your own design patterns!

About Hayim Makabee

Veteran software developer, enthusiastic programmer, author of a book on Object-Oriented Programming, co-founder and CEO at KashKlik, an innovative Influencer Marketing platform.
This entry was posted in Design Patterns, OOD and tagged , . Bookmark the permalink.

2 Responses to Collecting Design Patterns

  1. sfridman says:

    Other professions has long supported this dual model, as every Doctor in the hospital has his Stethoscope, but a Heart Surgeon, Dentist, or have also their own set of tools.
    SW Eng. is a relative new profession, but still there is plenty of sharing (due to the proximity of our profession to internet and collaboration). As a sample, OOPSLA – (now SPLASH) has been doing design patterns for more than two (!) decades now. They published and debated contributions of specific DP ranging from vertical domains (e.g. mobile, financial) to horizontal domains (e.g. distributed systems, clouds).
    Tools are, by definition almost, a form of “stable, proven, reusable, and functional” entities, that are optimized for solving a problem or a set of problems, and did so over a period of time and a range of similar situations. But as technology advances so quickly, fewer perhaps than expected tools mature to be recognised, while ad-hoc solutions fly-by and evolve before a mould can cast them in iron.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s