7 ms·

It's a very good article. I wish I knew how to find this at the time when it was written. I remember when I first discovered the pattern, at a job I took 10 ye

It's a very good article. I wish I knew how to find this at the time when it was written. I remember when I first discovered the pattern, at a job I took 10 years after this article. The codebase seemed so clean, easy to evolve and test, even for a newbie and 'half programmer' as me - my mind was blown. I was thinking - what kind of black magic is this ?! Say you're new to programming. What's the best place today to learn about design patterns (with python examples, since it's the most used language for beginners) in an easy and accessible way ?

mcnichol 3y ago
Head First Design Patterns. It's a recent and very friendly introduction to the popular Gang of 4 - Object Oriented Programming book. I love this part of the journey for folks because it opens the door to a world of possibilities that has dramatically more structure and form. Thoughts and ideas become less "what if.." and more puzzling together the best interactions between certain design implementations. At risk of rattling on endlessly in my excitement for you, TDD became a very interesting and enjoyable way (for me at least) to implement these patterns and gain a better understanding. I think you'll find Martin Fowler, TDD, and IoC/DI are peas in a pod. (I realize you said Python and this was Java. I'll see if I can find something Python friendly. If you'd like to try your hand with Java....I highly highly recommend Spring Framework and more specifically Spring Boot. Spring is an IoC Container Framework where the Dependency Injection is done for you on the fly. So much to throw at someone but if you'd like to connect on it, I'd be more than happy to give you a running start.)
- uptownhr 3y ago
  I would love to pair with someone that works through TDD. I personally tried it a few times in the past and constantly got stuck for one reason or another. My conclusion is that testing is hard and guides and articles online don't do it justice. Anyone love and practice TDD and want to help another engineer out, please reach out :)
  - deleted 3y ago
    [deleted]
  - mcnichol 3y ago
    https://exercism.org https://exercism.org Testing Specifically: https://exercism.org/docs/tracks/python/tests https://exercism.org/docs/tracks/python/tests I really enjoyed working with my engineers on this site. A lot has changed since I used it last but the idea being it gives you small bite size challenges to test and exercise testing muscles. Below turned into a bit of an impassioned rant/soapbox. I still wanted to share in case it offers any support for you on your journey. You are absolutely right. I spent a good portion of my life testing code on a "line coverage" basis to satisfy management. It was hard to see the value in it when I viewed it as this necessary evil. I think it is hard because we are often left boiling an ocean of a problem when trying to build software or needing to implement "this thing" before I can do "that thing". Where do I even start? The setup eventually becomes so much that it really brings into question whether it was all worth it. One thing I can say is, at least for me, TDD was something I had to see done well before I could start doing it. I was never strong enough to understand from an article, book, or video. I paid an expert to pair with me who, himself, got wrapped around the axle trying to implement the simplest of structures. Ultimately it came down to me working with some folks who had exercised the "muscles" of implementing the practice and had several tools that made the process feasible. Intellij for Java was core, shortcuts, having one side of my screen the test, the other side implementation. Autorunning tests, a simple pipeline that tested, built, etc. I just needed to see what good looked like to at least start forming an opinion on what was possible for me. Eventually I learned to take smaller and smaller chunks at a time. You want to write an API, sure. Let's just send a {curl equivalent in your preferred language} to this endpoint and get a 200 OK response. Alright, now let's make sure this header is present. Try not to solve for the future as much as addressing what is in front of you at the moment, or maybe the next couple hours. You'll eventually notice common traits APIs have, database objects have, business logic you care about vs layers that don't belong to you and you can't really control anyway. There will be times that future issues will require you to build certain ways and you just won't know until you've been there a few times. I learned to approach things with what they called the Triple A Pattern (AAA) and each test had these three blocks of behavior: Arrange - Create all my objects, initialize, stub out skeletons I've maybe required parameters that I don't actually care about. Act - Execute my function, catch my object. Assert - Test that whatever I received is true, equal to "someVal" etc. There's honestly so much more to say and I glossed over so much. In the beginning I can distinctly remember this existential pain of pulling my repo from git and my environment not running, some cached dependency or browser session breaking things. I constantly felt like I wasn't understanding but I was ultimately learning how much I didn't know about the toolchain, the language itself, the editor I was using and I was finally getting a very clear understanding because I was looking for a very specific response. I started learning how to say, "Based on what I understand, I expect this to happen..." If I'm surprised, then I'm on a new adventure or maybe need to regroup. I think people believe TDD is supposed to be some panacea but it's only as good as the consistency someone leverages it with. Someone I really respected sold me when they said: "It just felt nice making some changes and knowing these things I tested for wouldn't pop up again in prod." That dread of 3am and my name being pulled into a Sev1 call because something was crashing over something simple (and it happened a few times) gave me anxiety constantly. You almost forget how much pressure you feel weighing you down until you leave that team, project, etc. It was a very freeing proposition that had the added bonus of not getting gaslit by people who didn't know what they were saying. I hope my experience offers some value as I really enjoyed sharing it.
- hirvi74 3y ago
  Why are Fowler's ideas so loved when such ideas lead the colossal failures? For example: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
  - mcnichol 3y ago
    I know personally Fowlers articles, some of the folks we hired who were former Thought work-ers, and my experience running through agile, SAFE, classic project management, and XP; nothing came close to the XP method. It was put up or shut up. If you said you could do it you can almost guarantee someone would ask you to show them and explain. A lot of "knowing something is not the same as knowing the name of something"
bb86754 3y ago
Dependency Injection Principles, Practices, and Patterns by Mark Seemann. Examples are in C# but it's a great book about OOP in general.
ayhanfuat 3y ago
If you are a beginner and you are coding in Python, I'd say hold off on the design patterns (as defined by the gang of four) but instead focus on idiomatic Python. The reason is many of the design patterns are baked into the language. It may create more confusion. For idiomatic Python, I can recommend two books that I've found really helpful: 1. Python Cookbook by David Beazley (it doesn't have the latest features like pattern matching but the 3rd edition uses Python 3 and it is still very relevant) 2. Fluent Python by Luciano Ramalho (the book itself is very good but it is also very valuable for the list of suggested readings at the end of each chapter).
- swaginator 3y ago
  I agree with this. Read both of those books on the job during my first year. Fluent Python really takes you from "Python as a scripting language" to "Python as a functional language". An example of why certain patterns aren't necessary in Python: I have two types of repositories, one that wraps my API calls, and one that wraps an in-memory database for unit testing. A module called repos.py chooses which of these to instantiate when it is loaded based off an environment variable. Because every module in Python is loaded once, every file/class that needs a repository for data access can import from repos.py and receive an instantiated repository object. There is no need for dependency injection because the dependency can be imported from a module, and the module can be modified at runtime. This is extremely powerful too, since, so long as my in-memory repository and API repository have the same behavior, I can write a test suite that doubles as both unit tests and integration tests, all I need to do is change a single environment variable. I think Java's limitation of "one class one file" and no support for first-class functions made design patterns necessary. Then you try out a language with some functional features and you're like "oh wait, that was just a workaround for what other languages have always been able to do".
tester756 3y ago
>hat's the best place today to learn about design patterns (with python examples, since it's the most used language for beginners) in an easy and accessible way ? https://en.wikipedia.org/wiki/Result_type https://en.wikipedia.org/wiki/Result_type https://github.com/rustedpy/result https://github.com/rustedpy/result
nicklecompte 3y ago
I would second ayhanfuat's comment[1] - if the programming beginner is at the level that we'd prefer to show them Python over Java or C#, then they probably aren't ready for understanding these design patterns. The other thing is that Python doesn't actually seem like a good language to discuss these abstractions compared to Java or C#: it's dynamically/gradually typed and in general dependencies are handled in a more "UNIX"-y way. In particular Python doesn't have first-class interfaces (at least last I checked, maybe mypy has something?). But statically-checked first-class interfaces are critical for why e.g. the service locator pattern works "seamlessly"[2] in real-life Java/C# codebases with lots of people doing lots of different things. My gut is that a lot of inversion-of-control design patterns don't actually work so well in practical Python compared to just throwing things in a dictionary/etc and using strings + careful unit testing. I do see there are some service locator Python packages so maybe I am being too closed-minded. But for teaching C#/Java is probably a better choice. [1] https://news.ycombinator.com/item?id=39459732 https://news.ycombinator.com/item?id=39459732 [2] I have been mystified by too many null pointers to say this with a straight face. But when the bugs are squashed it really does manage a "magical" level of complexity.
- polotics 3y ago
  Wow, are you really sure you've updated your priors? This notion that Python is for programming beginners as opposed to Java/C# has aged quite a bit has it not? In other news, ten years on the game's been up a while now, Fowler's profusion of wordage plastered onto simple functional concept, eg. in the present case: partial function application, doesn't really fly so well, even in the enterprise.
bobfromhuddle 3y ago
If you're new to programming, steer clear of design patterns. If you're a working python programmer who's curious about how other ecosystems use design patterns, try https://www.cosmicpython.com/ https://www.cosmicpython.com/

mcnichol 3y ago

Head First Design Patterns. It's a recent and very friendly introduction to the popular Gang of 4 - Object Oriented Programming book. I love this part of the journey for folks because it opens the door to a world of possibilities that has dramatically more structure and form. Thoughts and ideas become less "what if.." and more puzzling together the best interactions between certain design implementations. At risk of rattling on endlessly in my excitement for you, TDD became a very interesting and enjoyable way (for me at least) to implement these patterns and gain a better understanding. I think you'll find Martin Fowler, TDD, and IoC/DI are peas in a pod. (I realize you said Python and this was Java. I'll see if I can find something Python friendly. If you'd like to try your hand with Java....I highly highly recommend Spring Framework and more specifically Spring Boot. Spring is an IoC Container Framework where the Dependency Injection is done for you on the fly. So much to throw at someone but if you'd like to connect on it, I'd be more than happy to give you a running start.)

uptownhr 3y ago
I would love to pair with someone that works through TDD. I personally tried it a few times in the past and constantly got stuck for one reason or another. My conclusion is that testing is hard and guides and articles online don't do it justice. Anyone love and practice TDD and want to help another engineer out, please reach out :)
- deleted 3y ago
  [deleted]
- mcnichol 3y ago
  https://exercism.org https://exercism.org Testing Specifically: https://exercism.org/docs/tracks/python/tests https://exercism.org/docs/tracks/python/tests I really enjoyed working with my engineers on this site. A lot has changed since I used it last but the idea being it gives you small bite size challenges to test and exercise testing muscles. Below turned into a bit of an impassioned rant/soapbox. I still wanted to share in case it offers any support for you on your journey. You are absolutely right. I spent a good portion of my life testing code on a "line coverage" basis to satisfy management. It was hard to see the value in it when I viewed it as this necessary evil. I think it is hard because we are often left boiling an ocean of a problem when trying to build software or needing to implement "this thing" before I can do "that thing". Where do I even start? The setup eventually becomes so much that it really brings into question whether it was all worth it. One thing I can say is, at least for me, TDD was something I had to see done well before I could start doing it. I was never strong enough to understand from an article, book, or video. I paid an expert to pair with me who, himself, got wrapped around the axle trying to implement the simplest of structures. Ultimately it came down to me working with some folks who had exercised the "muscles" of implementing the practice and had several tools that made the process feasible. Intellij for Java was core, shortcuts, having one side of my screen the test, the other side implementation. Autorunning tests, a simple pipeline that tested, built, etc. I just needed to see what good looked like to at least start forming an opinion on what was possible for me. Eventually I learned to take smaller and smaller chunks at a time. You want to write an API, sure. Let's just send a {curl equivalent in your preferred language} to this endpoint and get a 200 OK response. Alright, now let's make sure this header is present. Try not to solve for the future as much as addressing what is in front of you at the moment, or maybe the next couple hours. You'll eventually notice common traits APIs have, database objects have, business logic you care about vs layers that don't belong to you and you can't really control anyway. There will be times that future issues will require you to build certain ways and you just won't know until you've been there a few times. I learned to approach things with what they called the Triple A Pattern (AAA) and each test had these three blocks of behavior: Arrange - Create all my objects, initialize, stub out skeletons I've maybe required parameters that I don't actually care about. Act - Execute my function, catch my object. Assert - Test that whatever I received is true, equal to "someVal" etc. There's honestly so much more to say and I glossed over so much. In the beginning I can distinctly remember this existential pain of pulling my repo from git and my environment not running, some cached dependency or browser session breaking things. I constantly felt like I wasn't understanding but I was ultimately learning how much I didn't know about the toolchain, the language itself, the editor I was using and I was finally getting a very clear understanding because I was looking for a very specific response. I started learning how to say, "Based on what I understand, I expect this to happen..." If I'm surprised, then I'm on a new adventure or maybe need to regroup. I think people believe TDD is supposed to be some panacea but it's only as good as the consistency someone leverages it with. Someone I really respected sold me when they said: "It just felt nice making some changes and knowing these things I tested for wouldn't pop up again in prod." That dread of 3am and my name being pulled into a Sev1 call because something was crashing over something simple (and it happened a few times) gave me anxiety constantly. You almost forget how much pressure you feel weighing you down until you leave that team, project, etc. It was a very freeing proposition that had the added bonus of not getting gaslit by people who didn't know what they were saying. I hope my experience offers some value as I really enjoyed sharing it.
hirvi74 3y ago
Why are Fowler's ideas so loved when such ideas lead the colossal failures? For example: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
- mcnichol 3y ago
  I know personally Fowlers articles, some of the folks we hired who were former Thought work-ers, and my experience running through agile, SAFE, classic project management, and XP; nothing came close to the XP method. It was put up or shut up. If you said you could do it you can almost guarantee someone would ask you to show them and explain. A lot of "knowing something is not the same as knowing the name of something"

bb86754 3y ago

Dependency Injection Principles, Practices, and Patterns by Mark Seemann. Examples are in C# but it's a great book about OOP in general.

ayhanfuat 3y ago

If you are a beginner and you are coding in Python, I'd say hold off on the design patterns (as defined by the gang of four) but instead focus on idiomatic Python. The reason is many of the design patterns are baked into the language. It may create more confusion. For idiomatic Python, I can recommend two books that I've found really helpful: 1. Python Cookbook by David Beazley (it doesn't have the latest features like pattern matching but the 3rd edition uses Python 3 and it is still very relevant) 2. Fluent Python by Luciano Ramalho (the book itself is very good but it is also very valuable for the list of suggested readings at the end of each chapter).

swaginator 3y ago
I agree with this. Read both of those books on the job during my first year. Fluent Python really takes you from "Python as a scripting language" to "Python as a functional language". An example of why certain patterns aren't necessary in Python: I have two types of repositories, one that wraps my API calls, and one that wraps an in-memory database for unit testing. A module called repos.py chooses which of these to instantiate when it is loaded based off an environment variable. Because every module in Python is loaded once, every file/class that needs a repository for data access can import from repos.py and receive an instantiated repository object. There is no need for dependency injection because the dependency can be imported from a module, and the module can be modified at runtime. This is extremely powerful too, since, so long as my in-memory repository and API repository have the same behavior, I can write a test suite that doubles as both unit tests and integration tests, all I need to do is change a single environment variable. I think Java's limitation of "one class one file" and no support for first-class functions made design patterns necessary. Then you try out a language with some functional features and you're like "oh wait, that was just a workaround for what other languages have always been able to do".

tester756 3y ago

>hat's the best place today to learn about design patterns (with python examples, since it's the most used language for beginners) in an easy and accessible way ? https://en.wikipedia.org/wiki/Result_type https://en.wikipedia.org/wiki/Result_type https://github.com/rustedpy/result https://github.com/rustedpy/result

nicklecompte 3y ago

I would second ayhanfuat's comment[1] - if the programming beginner is at the level that we'd prefer to show them Python over Java or C#, then they probably aren't ready for understanding these design patterns. The other thing is that Python doesn't actually seem like a good language to discuss these abstractions compared to Java or C#: it's dynamically/gradually typed and in general dependencies are handled in a more "UNIX"-y way. In particular Python doesn't have first-class interfaces (at least last I checked, maybe mypy has something?). But statically-checked first-class interfaces are critical for why e.g. the service locator pattern works "seamlessly"[2] in real-life Java/C# codebases with lots of people doing lots of different things. My gut is that a lot of inversion-of-control design patterns don't actually work so well in practical Python compared to just throwing things in a dictionary/etc and using strings + careful unit testing. I do see there are some service locator Python packages so maybe I am being too closed-minded. But for teaching C#/Java is probably a better choice. [1] https://news.ycombinator.com/item?id=39459732 https://news.ycombinator.com/item?id=39459732 [2] I have been mystified by too many null pointers to say this with a straight face. But when the bugs are squashed it really does manage a "magical" level of complexity.

polotics 3y ago
Wow, are you really sure you've updated your priors? This notion that Python is for programming beginners as opposed to Java/C# has aged quite a bit has it not? In other news, ten years on the game's been up a while now, Fowler's profusion of wordage plastered onto simple functional concept, eg. in the present case: partial function application, doesn't really fly so well, even in the enterprise.

bobfromhuddle 3y ago

If you're new to programming, steer clear of design patterns. If you're a working python programmer who's curious about how other ecosystems use design patterns, try https://www.cosmicpython.com/ https://www.cosmicpython.com/