Classic Design Patterns: Where Are They Now - Brandon Rhodes - code::dive 2022
Вставка
- Опубліковано 11 гру 2022
- Classic Design Patterns: Where Are They Now
About the speaker - Brandon Rhodes
Brandon Rhodes is best known as a popular speaker at Python conferences, but his open source projects include C and C++ and even bits of JavaScript.
His still maintains the old PyEphem astronomy module he wrote in the 1990s, while his more recent Skyfield library helps Python programmers determine the positions of planets, comets, and satellites with high precision.
His ‘Python Patterns’ website helps programmers wade through the conflicting claims of several famous design patterns to determine which ones work well in a modern dynamic programming language. - Наука та технологія
This talk is a gem of wisdom.
This talk resonates a lot with features offered by functional paradigm - immutable data separated from methods, explicit flow, expressions instead statements.
Thank you so much for explaining why I've been in software for 5+ years and have never seen most of these.
I suppose, you are using iterators or decorators, for example, every day but it hidden under the hood.
underrated talk.
This is very much appreciated. Thank you!
I believe "Inversion of Control" is a common strategy to avoid that "Domino" programming you describe. if im understanding you correctly?
I also don't think that the Strategy Pattern necessarily means you have to pass it a class which owns the method. I think injecting a function into a class would still be considered using the strategy pattern, its just a more modern implementation for languages that are less rigid around classes. Even in java you could just use a Functional Interface as the property instead of a class.
I think you're right on the point that whenever a routine (function or a class) is passed to another routine where the incoming routine provides some facilities to be used in the receiving routine, that can be considered strategy pattern.
Strategy Pattern is Dependency Injection
In Smalltalk, the Singleton pattern really was there to handle things like "true". Since everything is an object in Smalltalk, including "true" and "false", they quickly realized that there was no reason to have a gazillion "true" objects, as that would lead to massive memory overhead. So, having a single, well-known, globally accessible instance of "true" made a lot more sense than everybody creating their own version of it whenever they needed to test something against true.
Understanding design patterns is a lot easier if you understand just a little Smalltalk. (Note that this sometimes means "when not to use them because they solve problems not relevant to your language")
Brilliant talk. Why so little views((
Design Patterns is/are primarily about providing features not available in your programming language. In the 1950s, subroutines were a design pattern. Nowadays, it's a machine language opcode.
2) - Getters and Setters are actually a mortal sin. You might GET your bank balance, but you never ET it ... you deposit or withdraw from your bank acount.
I like the beginning part when you cross-out patterns and say modern language has done that for you, May be an more interesting topic is "design patterns in model language"
Hmm good presentation but i think that observer is used in reactive programming and proxy is a mediator just in a different context.
I think the prototype design pattern is used a lot in Game Development?
On soap webservice I thought its use there
The prototype pattern is everywhere in JS tho
My hot take: You probably haven't seen most of these patterns if your only modern reference language is Python.
Okay, something must be a bit wrong when he talks about consumers and producers, and generators.
Isn't it the case that when you pass an entire generated list, it is still being iterated through an iterator? And a generator only returns an iterator, it's basically syntactic sugar for an iterator class. The list itself has an __iter__ method on it, which returns an iterator, which is iterating through the list lazily. That is if you use a standard for loop, of course. So I don't see the point here, specifically in the case of Python. In other languages, where you can actually iterate through mathematical operations (incrementing an index), it may make sense to not rely on an interator... But aside from that, you still kinda do, no?
Even if we generate the list externally and pass it that, how is that a shallow call stack? It may actually make more sense to generate the iterator, and simply pass the iterator, if we are so worried about letting the consumer do decide what they want to consume. In any case, Python does exactly that when we pass it a list. It is passed by reference and iterating through it is basically calling the __iter__ method to return an iterator. By passing the result of calling the gen function, we are actually passing an iterator, so it is virtually the same.
###
As for his other remarks, many of them are either wrong, or miss the point entirely. Strategy pattern is still used, it's called dependency injection. Basically the same thing. The observer pattern is still pretty much how event-based systems work, especially in UI. Maybe not 100% the same, but the pattern is still there. Pub/Sub is technically a more complex observer. And React most certainly does either Observer or Mediator, depending on how you think about it.
The memento pattern is not what he described at all. I have no idea what he described, never heard of it like that before, but definitely not the memento. The memento depends on in-memory storage, not DB storage. While we may want to persist that state in a DB, that's not its primary purpose. The primary purpose is to provide some kind of undo functionality.
Whenever you try to make things invulnerable to all complications, you are trying to make the world foolproof ... but the world will just create a more powerful fool.
object oriented programming sucks