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

21–30 of 112 posts

Re: Design Patterns – A comprehensible guide

#21

Post by runT1ME »

hota_mazi wrote: post #17
ilugaslifg wrote: post #3

Object-oriented programming is a disease, and I can't wait until we're collectively done with it. 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. The fact that there's this encyclopedia of hundreds of discrete things with arcane toxic names that practitioners are required to individually learn and…

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

Re: Design Patterns – A comprehensible guide

#22

Post by ktRolster »

krapp wrote: post #14
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.

You can implement design patterns with functions, but functions themselves are not a design pattern.

Says someone who's never used a language that only had gosub. Figuring out how to use functions appropriately is one of the most important skills of software engineering.

Re: Design Patterns – A comprehensible guide

#23

Post by keithnz »

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.

Grady booch was working on a "handbook of software architecture". What he was doing is go to companies and look at how systems have been built.

there's a presentation https://pdfs.semanticscholar.org/242a/61777fd7f0f7ded8d9326e...

He was looking at the structure, and the patterns in real world systems

Re: Design Patterns – A comprehensible guide

#24

Post by krapp »

icebraining wrote: post #20
krapp wrote: post #14

Earlier quoted context omitted.

You can implement design patterns with functions, but functions themselves are not a design pattern.

Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on t…

To me, functions alone aren't abstract enough to be considered a design pattern. If they were, any arbitrary chunk of code, however disorganized, could be considered an implementation of that pattern as long as it used functions, which seems counter intuitive.

Re: Design Patterns – A comprehensible guide

#25

Post by iak8god »

revscat wrote: post #18
catshirt wrote: post #15

Earlier quoted context omitted.

i enjoyed the conviction.

There is far too much conviction in the world. One of the reasons HN is so enjoyable is that the discussions tend to avoid the heat that you can find just about anywhere else.

> There is far too much conviction in the world.

Are you sure? :)

Re: Design Patterns – A comprehensible guide

#26

Post by sdflkd »

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.

Agreed. Anyone who thinks this hasn't played enough with FP languages.

Re: Design Patterns – A comprehensible guide

#27

Post by joe_the_user »

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's not so much they're contrived but that starting with real world, physical examples is ultimately not helpful. OO objects are not physical objects and the sooner someone realizes this, the better.

Re: Design Patterns – A comprehensible guide

#28

Post by krapp »

ktRolster wrote: post #22
krapp wrote: post #14

Earlier quoted context omitted.

You can implement design patterns with functions, but functions themselves are not a design pattern.

Says someone who's never used a language that only had gosub. Figuring out how to use functions appropriately is one of the most important skills of software engineering.

>Says someone who's never used a language that only had gosub.

If using GOTO in Windows batch files counts, then I kind of have.

>Figuring out how to use functions appropriately is one of the most important skills of software engineering.

Yes, but that's not so much a design pattern as discipline. Knowing what patterns to use and when.

Re: Design Patterns – A comprehensible guide

#29

Post by ktRolster »

krapp wrote: post #24
icebraining wrote: post #20

Earlier quoted context omitted.

Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on t…

To me, functions alone aren't abstract enough to be considered a design pattern. If they were, any arbitrary chunk of code, however disorganized, could be considered an implementation of that pattern as long as it used functions, which seems counter intuitive.

There are good ways and bad ways to use functions, just like any design pattern.

Re: Design Patterns – A comprehensible guide

#30

Post by opk »

The main value of the design patterns is that they have given names to things that were already common and fairly intuitive to a half decent programmer.

But I've come across many people trying to use them as a guide for how to write code - and misunderstanding them. Factory in particular is often misunderstood. It is mainly useful when you have parallel class hierarchies not as some odd wrapper around all the constructors in the software.

Post reply on HN