Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design patterns you should unlearn in Python

lihil.cc

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Design patterns you should unlearn in Python

#61

Post by acedTrex »

xigoi wrote: post #44
acedTrex wrote: post #38

I don't agree with the builder pattern. For basic objects yes its a bit silly. But the ACTUAL value of the builder pattern is when you want to variadically construct an object. Create the base object, then loop or otherwise control flow over other state to optionally add stuff to the base object. Then, additionally, the final "build" call can run validations over the set of the complete object. This is useful in case…

> Create the base object, then loop or otherwise control flow over other state to optionally add stuff to the base object. That’s what list comprehensions are for. > Then, additionally, the final "build" call can run validations over the set of the complete object. The constructor function can do that too.

The constructor can not do it because the constructor does not have all the data. This is lazy evaluation.

Re: Design patterns you should unlearn in Python

#62

Post by dgfitz »

kccqzy wrote: post #39
taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

I don't however appreciate that the author doesn't actually know about Java or C++ well enough such that they are spewing falsehoods about Java or C++. Saying things like "There’s no clean way to say 'this is private to this file' (in C++)" is just bonkers. The author is well intentioned, but coming up with the wrong reason is worse than not offering any reason.

I had that thought too, and thought I must have misunderstood something. I generally assume I’m the dummy. :)

Re: Design patterns you should unlearn in Python

#64

Post by orwin »

motorest wrote: post #46
taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

> I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. I don't agree at all. I feel that those who criticise design patterns as solution to practical problems are completely missing the point of design patterns, and the whole reason they have the name the have: design patterns. I'll explain. Design patterns are…

I mean, people usually call those 'feature' when they're built-in. I would never call 'lazy evaluation' in Haskell a design pattern, because it's part of the language.

If I have to implement something similar myself in C++ however, I'll use a niche design pattern.

Re: Design patterns you should unlearn in Python

#65

Post by AceJohnny2 »

taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

The explanations are great! The condescension, not so much.

> Simple: we just use the language like it was meant to be used.

> Use Default Arguments Like a Normal Human

etc

Re: Design patterns you should unlearn in Python

#66

Post by matusp »

NeutralForest wrote: post #11

I've never seen anybody do that... In Python you can use a module as a singleton (mentioned in the article). Or provide some data like: from functools import lru_cache class Whatever: pass @lru_cache(maxsize=1) def get_whatever(): return Whatever() And use `get_whatever` as your interface to get the resource.

You can implement a singleton class that works properly quite easily. The advantage is that most people are familiar with singleton as a pattern, and it is a self contained chunk of code. The cache solution you provided works, but its functionality is not obvious and it feels very hacky to me. Somebody's going to initialize Whatever in another way down the line without using the cached function...

Re: Design patterns you should unlearn in Python

#67

Post by orwin »

AtlasBarfed wrote: post #60
mrweasel wrote: post #34

Earlier quoted context omitted.

You can overwrite pretty much anything in Python at runtime, and the mock tooling in the standard library can help you with that, if you can't straight up just override a method or object.

Global vars? So with a Singleton what you can do at least in Java land is have your service invoke the method to get the Singleton semi-global object. So you can mock that method invocation to return a different object. So you basically have the local object to play with in your test and won't be affecting any actual real global state But basically the article was just saying just use global variables. Does python ha…

I'm tired and I'm not sure I understood your question correctly, sorry if it doesn't address your point:

In python test library, you have something called 'monkeypatch' that allows you to intercept calls to specific functions or classes and set the response yourself (I mostly use it to mock API responses tbh but it can do a lot more, an really complex operations). Monkeypatch only operate in the scope of the function or file it's written in (I think. I only remember using it in unit test functions).

Re: Design patterns you should unlearn in Python

#68

Post by AtlasBarfed »

orwin wrote: post #67
AtlasBarfed wrote: post #60

Earlier quoted context omitted.

Global vars? So with a Singleton what you can do at least in Java land is have your service invoke the method to get the Singleton semi-global object. So you can mock that method invocation to return a different object. So you basically have the local object to play with in your test and won't be affecting any actual real global state But basically the article was just saying just use global variables. Does python ha…

I'm tired and I'm not sure I understood your question correctly, sorry if it doesn't address your point: In python test library, you have something called 'monkeypatch' that allows you to intercept calls to specific functions or classes and set the response yourself (I mostly use it to mock API responses tbh but it can do a lot more, an really complex operations). Monkeypatch only operate in the scope of the function…

The answer if I understand correctly is if you want to use testing frameworks in Python, you should probably not be using global variables and you should probably actually be using the Singleton pattern.

Re: Design patterns you should unlearn in Python

#69

Post by layer8 »

taylorallred wrote: post #10

I really appreciate how this article explains why certain design patterns became a thing. Usually, it was to address some very practical problem or limitation. And yet, a lot of younger programmers treat these patterns like a religious dogma that they must follow and don't question if they really make sense for the specific situation they are in.

The main motivation for the concept of design patterns is to give unique names to existing programming patterns, so that when someone says “Strategy pattern”, everyone knows what pattern that refers to, and vice versa that the same pattern isn’t called ten different things. It’s to make communication about program design efficient, by defining a vocabulary of patterns that tend to reoccur, and a common structure for describing them. Not all patterns were successful in that way, but it’s the main idea behind design patterns.

The question of when a using a given pattern is appropriate is orthogonal to that. The fact that a named pattern has been defined doesn’t imply a recommendation to use it across the board. It depends on the context and on design forces, and those change with time and circumstances. Anti-patterns are patterns as well.

It’s a pity that the idea of design patterns ended up (after the pattern language craze faded) being almost exclusively associated with the specific patterns named and described in the GoF book.

Post reply on HN