From the course: C#: Design Patterns Part 1

Using software design patterns - Python Tutorial

From the course: C#: Design Patterns Part 1

Start my 1-month free trial

Using software design patterns

“

- [Instructor] You see something once and it's new. The second time, it's a coincidence. After that, it's a pattern. How do we recognize patterns and use them? When coding, only in the very edges of what is possible do you find new problems. Most of the issues we encounter have been solved before, and it's a question of the correct set of search terms to find the appropriate solution. The problem solving comes as part of applying that solution to a more specific scenario. Remember that design patterns are about recurring problems. Patterns are not created in a vacuum. They are only design patterns because the problem they solve has needed to be solved repeatedly. Design patterns are records of previously encountered architectural problems. The first step to recognizing the scenarios for these patterns is to learn them, to understand the why and the when. If you're someone early in your career, this gives you the chance to have seen a usage of a pattern before you need it, making it easier to apply the knowledge in the future. As you gain experience, reviewing patterns allows you to see them in the light of experience and understand the patterns and their applications more deeply. To use a design pattern, you first have to understand the general purpose of it. We'll overview the Gang of Four patterns later in this chapter. The next step is to find previous implementations of the pattern and learn from them. Design patterns are big enough part of the history of building software that we can find lots of existing examples in real situations. With the prevalence of open-source software, find code on GitHub or other public places that can show you how someone else implemented a pattern. Finally, try it out. Learning from small examples is valuable to get started, but trying out a pattern in your real scenario is where you can really begin to see the value or the consequences of it. Do an architectural proof of concept for a pattern to see if it will add value or improve your solution in the long term. When you do architect code with a pattern in mind, write a recognizable version of that pattern, spend the time thinking about naming. It's one of the best ways to make readable code. Don't name every factory you create factory. In some situations, it can be useful, but not all the time. Finding the balance may not be obvious at first, but don't be afraid to rename as you go to make your code as understandable as possible. Future you will constantly thank past you for the effort. We're going to be doing all these things as part of the patterns that we cover, but we won't be covering all the patterns that are out there. Rather than just focusing on the specific patterns that we cover, focus on how we analyze an examine the pattern so that you can use that to open up new patterns we haven't covered. Finally, there's no substitute for using the pattern for real. The more you use it, the more you'll see how it operates and where it will be useful in the future. But spending the time learning it now will give you the best possible headstart.

Contents