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

Design Patterns – A comprehensible guide

github.com

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Design Patterns – A comprehensible guide

#31

Post by hackits »

TillE wrote: post #2

I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived. Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.

Questions like “Which paradigm is better for modeling the real world” are virtually meaningless. The choice depends upon how the world is conceptualized, and what additional properties are expected of the model.

Re: Design Patterns – A comprehensible guide

#32

Post by rezashirazian »

TillE wrote: post #2

I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived. Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.

A while ago, as an exercise I decided to implement some of the more popular design patterns in Swift, using more real life like examples. If you're interested you can find it here: https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

Re: Design Patterns – A comprehensible guide

#34

Post by rezashirazian »

sna1l wrote: post #4
TillE wrote: post #2

I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived. Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.

It would be great if there was a resource with real world examples, since I have this exact same problem.

I implemented some of the more popular design patterns using more real life like examples. You might find them useful :

https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

Re: Design Patterns – A comprehensible guide

#35

Post by BuuQu9hu »

ktRolster wrote: post #12

The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.

Design patterns are patterns which can be used for designs. All patterns can be used for designs; "design pattern" as a phrase merely signals that the pattern was described in a certain book.

Functions are too simple and concrete to be patterns. A function is a mapping from one set to another. Even category theory manages to fully generalize functions several different ways without managing to define something as general as a pattern.

So, you might ask, what are patterns? Patterns are things which repeat somehow. That's it. There might be more to it, but I have yet to find it.

I'm glad that you like Lisp, but it's not the beginning nor the end of programming. For example, the Post correspondence problem is Turing-complete. So are Wang tiles. Where's your functions now?

Re: Design Patterns – A comprehensible guide

#36

Post by JamesBarney »

TillE wrote: post #2

I appreciate the effort, but one of my pet peeves with OO / design pattern examples is when they're completely contrived. Once you've understood the very basics of OO, I think talking about a door factory or a burger builder tends to obfuscate real-world usage more than it aids comprehension. I have this problem with most science/technology analogies, to be honest.

Right, stop making pained carpentry analogies. I couldn't build a wooden box to save my life, but I do have 7 years of professional software experience. I would much prefer if you drew from that experience.

Re: Design Patterns – A comprehensible guide

#37

Post by ktRolster »

BuuQu9hu wrote: post #35
ktRolster wrote: post #12

The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.

Design patterns are patterns which can be used for designs. All patterns can be used for designs; "design pattern" as a phrase merely signals that the pattern was described in a certain book. Functions are too simple and concrete to be patterns. A function is a mapping from one set to another. Even category theory manages to fully generalize functions several different ways without managing to define something as gen…

I've read your comment several times, but I'm not sure what you're saying, actually. Certainly functions have been described in several books. No one is said that functions are the only design pattern.

Re: Design Patterns – A comprehensible guide

#38

Post by hackits »

hackits wrote: post #19
djeunneun wrote: post #16

Earlier quoted context omitted.

Why is it a disease, honest question.

To do OOP good requires a lot of forward thinking and careful planning. Though most of the two are lacking supply when you're dealing with large teams of programmers and you end up with some IFactoryAbstractInterfaceInvoker eg... the kingdom of nouns game. The other main concern was it was over-hyped with consultants running around to all businesses during the dot net time with xml with no empirical evidence to backu…

Just for clarification.

I'm not dishing OOP per say. My main concern is OOP emphasis (Java) is everything needs to be a class. There are times when there isn't a need for a noun for a bunch of functions that operate over a collection of abstract data types. The other problem is how OOP is first introduced to programmers. They're taught they need to categorizing everything into a taxonomy (classes) and inheritance. So the emphasis is incorrectly put on the art of taxonomy instead of getting the job done the most straight forward approach.

Re: Design Patterns – A comprehensible guide

#39

Post by hota_mazi »

runT1ME wrote: post #21
hota_mazi wrote: post #17

Earlier quoted context omitted.

> All of these abstractions, when rarely they are actually needed to express a program, can be naturally expressed within the type system, in a proper functional language. If you think FP is mutually exclusive with OOP, you understand neither. OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (…

>OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick). This is not true, ad hoc polymorphism works fine without subtype polymorphism.

You're absolutely right but you're not answering my objection.

Show me an example of a type class with five functions and then how I can reuse it while overriding one of these five.

Re: Design Patterns – A comprehensible guide

#40

Post by 0x54MUR41 »

In my opinion, iluwatar's design pattern guide [1] provides more examples than this. It gives not only implementation examples but also a class diagram and use case for each design pattern. The examples were implemented in Java.

[1]: https://github.com/iluwatar/java-design-patterns

Post reply on HN