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

101–110 of 110 posts

Re: Design patterns you should unlearn in Python

#101

Post by motorest »

hinkley wrote: post #54
motorest wrote: post #46

Earlier quoted context omitted.

> 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 see you’ve been downvoted. Design patterns aren’t solutions to common design problems. They’re after the fact descriptions of solutions for design problems. That’s the issue. That’s the beef. Everyone thought of that book as a cook book instead of a naturalists’ musings on an ecosystem, which is what they are. Those of us who designed before people discovered that stupid book were constantly asked what the differen…

> Design patterns aren’t solutions to common design problems. They’re after the fact descriptions of solutions for design problems. That’s the issue.

No, they are not. They describe a way to design something. They are called design patterns. It is in the name, already. Consider instantiating an object. You can have a factory, or you can pass a parameter object, you can implement a builder. Perhaps you can use a flywheel? In testing there is also object mothers.

Did you noticed that each term describes a very specific and concrete approach to tackle a single use case? There is no "after the fact" anything. Claiming design patterns is something you do "after the fact" reflects a complete failure of understanding what design patterns are and how they are used.

No wonder people complain about design patterns. They are complaining about their own failure to understand what they are and how they are used. Of course people complain about things they don't understand.

> Those of us who designed before people discovered that stupid book were constantly asked what the differences were between this pattern and that.

The book didn't discovered anything. At best it contributed to standardize names used for popular design patterns.

Also, the telltale sign that people are shit talking design patterns out of sheer ignorance,and willful ignorance, is the fact that there are over a dozen reference books on design patterns. Reference authors such as Martin Fowler even wrote themselves two or three books worth of patterns. But GoF is the only one being attacked all the time? Why? Because of ignorance.

Re: Design patterns you should unlearn in Python

#102

Post by motorest »

orwin wrote: post #64
motorest wrote: post #46

Earlier quoted context omitted.

> 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.

> I mean, people usually call those 'feature' when they're built-in.

No, that's specious reasoning. A message queue is still a message queue if you use one provided by the OS. An exception is still an exception even if it's provided as a standard component. A state machine is still a state machine regardless of how you choose to implement your concrete implementation.

Design patterns are all about the patterns followed when designing something. That's it.

Re: Design patterns you should unlearn in Python

#103

Post by motorest »

dragonwriter wrote: post #71
layer8 wrote: post #69

Earlier quoted context omitted.

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…

> The main motivation for the concept of design patterns is to give unique names to existing programming patterns No, naming them is not the main purpose, preserving and transmitting knowledge of what they are and what they are useful for, so that people aren't fofced to rediscover solutions to the same problems over and over again. [0] Naming is obviously important for that purpose, but isn't the main goal, but a me…

> No, naming them is not the main purpose, preserving and transmitting knowledge of what they are and what they are useful for, so that people aren't fofced to rediscover solutions to the same problems over and over again. [0] Naming is obviously important for that purpose, but isn't the main goal, but a means of supporting it.

Yes, this.

It's as if design patterns represents recurring patterns followed when designing something.

Wouldn't it be silly if architects spent their time shit-talking the silliness of referring to those holes added to walls to be covered by movable panes of glass as "windows"?

Somehow we're here seeing software developers do this sort of nonsense.

Re: Design patterns you should unlearn in Python

#104

Post by zelphirkalt »

mettamage wrote: post #98
zelphirkalt wrote: post #19

I have observed these "design pattern shoehorned into Python" so many times ... Great post. When you see these things done in a code base, you know that you got people, who would rather want to write Java working on it. Or maybe people who don't have the feel for Python as a language or something. First thing I looked up in the article was "singleton", as a sanity check, whether the article is any good. And yes, it s…

Best practices in software engineering seem to usually pertain to a particular language or set of languages. I've also noticed that authors usually don't notice that this is the case. In fact, I've pissed off some people in interviews for holding this view. We aren't really that empirical as an industry about best practices.

Exactly. Best practices, especially patterns are language dependent. I mean, it already starts with decorators. Even someone slightly familiar with Python will know, that Python has something called decorators. So how to use them? Which practices that people have in Java or similar language do they replace, make unnecessary? Programming is not a "one size fits all" kind of thing.

Re: Design patterns you should unlearn in Python

#105

Post by atoav »

zahlman wrote: post #93
atoav wrote: post #29

Earlier quoted context omitted.

I like method chaining (not the same as builder patterns) for code that needs to run chained operations on objects. It is not exacrly the same because each chained operation usually does more than just setting a variable. E.g. signal = Sine(freq=440.0, amp=1.0) .rectify() .gain(2.0) .center() .clip(0.5) Each of the methods may return a Signal object that can get processed by the next function, allowing you to chain t…

Just keep in mind that idiomatic Python expects https://en.wikipedia.org/wiki/Command%E2%80%93query_separati... ; if you return instances to support chaining, please return new instances rather than modifying the original in-place. Take the example set by the builtins; `list.append` etc. return `None` for a reason. cf. https://stackoverflow.com/questions/11205254 .

Good point.

Since the idea behind method chaining is a bit like UNIX pipes anyways, it would be silly (and unexpected) if commands later in the chain affected parts that came before, so you basically output a new instance each time. In my example above the signal wouldn't be a sine wave anymore after the first step, so that would make even less sense.

Editing existing instances is something I'd do for performance reasons only with no return value (lets exclude errors).

Re: Design patterns you should unlearn in Python

#106

Post by kuschku »

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…

In languages with currying, you could avoid the builder pattern by currying the constructor.

Re: Design patterns you should unlearn in Python

#107

Post by ddejohn »

mekoka wrote: post #74

If I had but one design pattern I would just LOVE to see disappear from Python, it's the need for super(). Don't get me wrong, super() is a clever piece of engineering, but if your code actually needs what it's useful for (C3 linearization, MRO, etc), then you've made things too complicated. I deplore the proliferation of libraries that have embraced the seductive, but ultimately deceptive ways of the mixin, because…

Completely agreed. The codebase I work on really badly abused multiple inheritance all over the place. Some of our classes are 5+ layers of inheritance deep.

All the code I've written since joining has used `typing.Protocol` over ABCs, simple dependency injection (i.e., no DI framework), no inheritance anywhere, and of course extensive type annotations... and our average test coverage has gone from around 6% to around 45%.

It's honestly baffling to see how insanely over-complicated most of the Python is that I see out in the wild, especially when you consider that like 90% of the apps out there are just CRUD apps.

Re: Design patterns you should unlearn in Python

#108

Post by [deleted] »

motorest wrote: post #103
dragonwriter wrote: post #71

Earlier quoted context omitted.

> The main motivation for the concept of design patterns is to give unique names to existing programming patterns No, naming them is not the main purpose, preserving and transmitting knowledge of what they are and what they are useful for, so that people aren't fofced to rediscover solutions to the same problems over and over again. [0] Naming is obviously important for that purpose, but isn't the main goal, but a me…

> No, naming them is not the main purpose, preserving and transmitting knowledge of what they are and what they are useful for, so that people aren't fofced to rediscover solutions to the same problems over and over again. [0] Naming is obviously important for that purpose, but isn't the main goal, but a means of supporting it. Yes, this. It's as if design patterns represents recurring patterns followed when designin…

[deleted]

Re: Design patterns you should unlearn in Python

#109

Post by necovek »

the__alchemist wrote: post #15

All good ones. I'll add this because A: It's common in Python, and B: There are suitable alternatives in the standard library: Conflating key/value lookups (dicts) with structured data (classes). They are both useful tools, but are for different purposes. Many python programmers (Myself many years ago included!) misused dicts when they should have been using dataclasses.

Dataclasses are relatively recent addition to the language: dicts were the most reasonable way to do it in the past, especially before type checking.

Under the hood, classes are also dict lookups, so really, this is mostly about adding type checking (unless you are also using slots).

Re: Design patterns you should unlearn in Python

#110

Post by nhumrich »

ddejohn wrote: post #30
nhumrich wrote: post #13

Earlier quoted context omitted.

People misunderstand the target audience and code base for the zen of python

Who's it for, then?

CPython core devs. Specifically talking about the CPython code base. Hence, the namespace comment, which doesn't really make sense in a purely python context.
Post reply on HN