From my experience patterns suffer from new devs thinking that patterns are guidelines for writing their code and that they should create code that is generic and implements patterns. (Yes if their job is implementing framework, not when their job is to use framework to build business app)

Like everyone totally forgot patterns are mainly for understanding existing systems like you use a framework - hey this looks like a factory let’s use one from the framework we built stuff with instead of implementing our own.

Besides of course every developer wanting to build framework so others adhere to what he built not the other way around ;)

▲

ahartmetz 4 days ago | parent | next [-]

I think of design patterns as possible solutions to certain problems. They should be used when the corresponding problem arises and their mental overhead is less than whatever the alternatives may be. I use them quite sparingly.

I don't find them very useful (today) to understand existing systems that don't intentionally use the patterns. They don't occur very often in well-designed systems in the first place, even less so unintentionally.

▲

ozim 4 days ago | parent [-]

First of all design patterns were not some god given solutions. Those are solutions gathered from existing implementations and authors just gave names to those solutions.

So they will be present in well designed systems just that they are not called by their „book name”.

Then I clearly see it in all new frameworks just that each framework has their own name for implementation of the pattern.

Patterns were mostly named so people can discuss easier about solutions that are there.

I will quote first sentence of foreword from my copy of the book „All well-structured object oriented architectures are full of patterns.”

▲

bluGill 4 days ago | parent [-]

Everything about object oriented from the book was added by editors because OO was the fad at the time. Most of the patterns apply to other styles of code. The authors were not confined to studying OO programs

▲

ozim 4 days ago | parent | next [-]

I don’t think we are writing about the same book: ”Design Patterns: Elements of Reusable Object-Oriented Software”.

That’s the one I write about, it has foreword from Grady Booch and was tied to OOPSLA meeting with C++ and Smalltalk examples. To add OOP stuff to it sounds like a different book because that book is about OOP by definition.

▲

bluGill 4 days ago | parent [-]

That book. The title was not from the main author.

▲

ahartmetz 4 days ago | parent [-]

AFAIK, the title is never chosen by the author (except maybe for the most successful ones)

	▲	bluGill 4 days ago \| parent [-]
		Pretty much and so you need to be careful about what you state about any book based on title. Though most of the time the title doesn't mislead this baddly. of course at the time they really thought nobody would question if oo was the best way to program so it didn't seem usefully misleading. Patterns apply to non oo programning as well

▲

3 days ago | parent | prev [-]

[deleted]

▲

whstl 4 days ago | parent | prev | next [-]

The original book completely failed to communicate that, though. This is common knowledge today, but wasn’t for a long time.

▲

user____name 3 days ago | parent | prev [-]

The biggest problem with "design pattern thinking" is that it suggest the solution to a given problem is always another abstraction.