Hogy vagy? :) I take you up on your word at the end of this article. Would love to have the continuation of this article with how further design patterns are useful for data science.
Any chance on a follow-up article with Bridge Pattern - to join data with model, Adapter Pattern - to do dependency inversion, Builder Pattern - to build complex classes.
Hi Laszlo, thanks for the write up – it's easy to understand, and yet very illustrative of the advantages of the programming patterns.
Since Python treats functions as first-class citizens, I wonder what you think about using functions instead of classes in some scenarios, like the StanfordNLPLemmatizer, which is a class with just one method besides the __init__, and while it have state (self.pipeline), it's instance is never used more than once.
Classes have (hidden) state, that can lead to subtle bugs, whereas (pure) functions do not, so while a class is more extensible as the need for complexity grows, for these "simple" examples, I think a function could do just as nicely... but I would love to hear your perspective on that!
I might be a little late to the party on this one but great article series! I love how you are able to illustrate these concepts with concrete and simple examples.
I'd love to see examples of the three above-mentioned patterns being applied to better understand where they can come in handy!
Szia Laszlo,
Hogy vagy? :) I take you up on your word at the end of this article. Would love to have the continuation of this article with how further design patterns are useful for data science.
Any chance on a follow-up article with Bridge Pattern - to join data with model, Adapter Pattern - to do dependency inversion, Builder Pattern - to build complex classes.
Koszonom, Timi
Hi Laszlo, thanks for the write up – it's easy to understand, and yet very illustrative of the advantages of the programming patterns.
Since Python treats functions as first-class citizens, I wonder what you think about using functions instead of classes in some scenarios, like the StanfordNLPLemmatizer, which is a class with just one method besides the __init__, and while it have state (self.pipeline), it's instance is never used more than once.
Classes have (hidden) state, that can lead to subtle bugs, whereas (pure) functions do not, so while a class is more extensible as the need for complexity grows, for these "simple" examples, I think a function could do just as nicely... but I would love to hear your perspective on that!
Best regards, Allan
Hey Laszlo,
I might be a little late to the party on this one but great article series! I love how you are able to illustrate these concepts with concrete and simple examples.
I'd love to see examples of the three above-mentioned patterns being applied to better understand where they can come in handy!