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

41–50 of 112 posts

Re: Design Patterns – A comprehensible guide

#41

Post by dang »

catshirt wrote: post #15
dang wrote: post #10

Earlier quoted context omitted.

This sort of heated rant makes for a bad HN comment, regardless of how correct your views are. It leads to flamewars, which we don't want here, so please don't post like this. Even if you took out the rantiness, the comment is still too generic to actually be saying anything. So to convert it to a good HN comment, you would need to both de-flamebait it and add information (e.g. specific examples).

i enjoyed the conviction.

I can appreciate that, but empirically we know from long experience that such comments lead to downward spirals. That's why the site guidelines are the way they are; it isn't to dampen conviction.

Re: Design Patterns – A comprehensible guide

#42

Post by dack »

opk wrote: post #30

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 constru…

I'm not sure what you mean by parallel class hierarchies. I use a factory if I have a class that needs to be able to make an instance of some other class, but shouldn't know about how to construct it (i.e. it doesn't need to know about the dependencies that other class might need to function).

Re: Design Patterns – A comprehensible guide

#43

Post by dack »

alashley wrote: post #33

I wish there was a resource that goes over design patterns with more abstract concepts/classes. I found the example in GoF to be somewhat useful but at a certain point (near the middle) I got lost in the details.

You want more abstract examples? Or more abstract patterns?

Re: Design Patterns – A comprehensible guide

#44

Post by mavelikara »

dkn wrote: post #13
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…

> arcane toxic names Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns. Just an inflammatory comment.

Yes, and quite rich coming from the crowd which throws around Functors, Applicatives, Monads, Kiesli, CoYoneda etc.

Re: Design Patterns – A comprehensible guide

#46

Post by Ace17 »

hackits wrote: post #38
hackits wrote: post #19

Earlier quoted context omitted.

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…

Please let's not equate OOP with Java.

There are actually OOP proponents like James Coplien and Trygve Reenskaug who think that Java is more "class-oriented" than "object-oriented", making it really hard to do proper OOP in Java.

Re: Design Patterns – A comprehensible guide

#47

Post by lomnakkus »

hota_mazi wrote: post #39
runT1ME wrote: post #21

Earlier quoted context omitted.

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

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

Huh? As I'm sure you're aware "type classes" != "classes", so I'm not sure why you're expecting them to be 'interchangeable' in this manner. It would be better to ask for some functionality (not a mechanism, as you're asking) and then show how one could be achieved[1] in one, but not the other.

Personally, I think any kind of implementation override is a code smell. If you need common functionality, just have a plain function outside your class and use that from both interface overrides.

[1] "Elegantly" or "expressively", one presumes. Of course everything can be achieved in any TC language.

Re: Design Patterns – A comprehensible guide

#48

Post by monocasa »

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.

I think they're just a victim of their own success. Particularly the iterative language concept of 'function' is by no means universal. They were kind of grafted onto mainframe architectures, and even the MIX from the original The Art of Computer Programming used self modifying code to perform subroutine calls.

Functions are an extremely common pattern more or less expected by every language, but I'd definitely call them patterns still.

Re: Design Patterns – A comprehensible guide

#49

Post by js8 »

hota_mazi wrote: post #39
runT1ME wrote: post #21

Earlier quoted context omitted.

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

You don't need overriding, in fact you should avoid it. All five functions are already valid operations on the type class (the data you have). If you want to add an operator, then you define another function (with another name) and call it. If the existing modules need to call that operator instead, change them to be explicit about what you're doing.

This is where OOP gets it wrong, because this situation leads to logical contradictions (breaking the type system), in particular, breaking of the LSP.

Re: Design Patterns – A comprehensible guide

#50

Post by js8 »

mavelikara wrote: post #44
dkn wrote: post #13

Earlier quoted context omitted.

> arcane toxic names Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns. Just an inflammatory comment.

Yes, and quite rich coming from the crowd which throws around Functors, Applicatives, Monads, Kiesli, CoYoneda etc.

I downvoted you - these are, unlike design patterns, very well-defined mathematical objects, but furthermore, you shouldn't use such a broad brush.
Post reply on HN