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

51–60 of 112 posts

Re: Design Patterns – A comprehensible guide

#51

Post by mavelikara »

js8 wrote: post #50
mavelikara wrote: post #44

Earlier quoted context omitted.

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.

> these are, unlike design patterns, very well-defined mathematical objects

IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field.

OO design patterns do not have mathematical foundations, but that does not make them arcane or toxic.

> you shouldn't use such a broad brush

Probably not, I agree.

Re: Design Patterns – A comprehensible guide

#53

Post by waynecolvin »

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 believe ktRolster may be refering to "Procedural Abstration". The term is used in SICP [1] (the Wizard Book using scheme, previously freshman programming text at MIT).

Abstration can take many forms. But can often be described as "seperating things that change and/or repeat from those that don't", or something like that.

The last paragraph may be a joke, or based on one of the Principles in the O'Reilly Design Patterns [2] book.

[1] https://mitpress.mit.edu/sicp/ [2] http://shop.oreilly.com/product/mobile/9780596007126.do

Re: Design Patterns – A comprehensible guide

#54

Post by mikekchar »

dack wrote: post #42
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).

I shouldn't speak for the OP, but I think they are referring to the fact that the factory pattern very naturally shows up when you also have the bridge pattern. You have 2 (or more) parallel class hierarchies and you need a way to construct the objects from the correct hierarchy.

You are also correct that it happens in other places too. Some people overuse it, though. They abstract out the construction of their objects for no reason at all. You already have a constructor -- usually there no need to have an object that contains all the constructors.

Re: Design Patterns – A comprehensible guide

#55

Post by mikekchar »

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.

A function is not a design pattern. A design pattern is a design that solves a problem. Without stating the problem to solve, you have not got a pattern. The OP stated that they used functions to organise their code, so you can imagine some problem that they were solving with functions. For another problem you might solve with functions, I was reminded recently that functions are an implementation of the state monad. If you read up about where you might use the state monad and why you need it, then perhaps you can get a better feeling for why a function is a good implementation of that pattern.

Re: Design Patterns – A comprehensible guide

#56

Post by alashley »

dack wrote: post #43
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?

More abstract examples.

Re: Design Patterns – A comprehensible guide

#57

Post by hackits »

Ace17 wrote: post #46
hackits wrote: post #38

Earlier quoted context omitted.

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.

There was a great talk by (David West) (https://www.youtube.com/watch?v=RdE-d_EhzmA&index=2&list=PLe...) that does make the point that objects have little, if any, value as a programming concept Because all the arguments about objects occurred in the context of programming they focused on things that really don't matter much, like single versus multiple inheritance, dot notation versus explicit messages for getting and setting or invoking methods; class hierarchies, friends, even the idea of a class.

He is more in favor programming of conceptualizing the real world as entities interacting with each other then designing systems that model those interactions. Thinking in objects allow one to design better systems that may not nesseary be represented as OOP in the language.

Jumping to the conclusion of his talk, he more or less advocating in using Abstract Data Type instead of objects. That's what I got from it anyway. Though it kind of reinforces that OOP changes depending on who you talk too.

Re: Design Patterns – A comprehensible guide

#58

Post by yoodenvranx »

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…

The one you mean is called "Factory Method Pattern" in the Gang of Four book. The other one should be called "Simple Factory" or something like that.

They are very different things which unfortunately have very similar names.

Re: Design Patterns – A comprehensible guide

#59

Post by yoodenvranx »

mikekchar wrote: post #54
dack wrote: post #42

Earlier quoted context omitted.

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

I shouldn't speak for the OP, but I think they are referring to the fact that the factory pattern very naturally shows up when you also have the bridge pattern. You have 2 (or more) parallel class hierarchies and you need a way to construct the objects from the correct hierarchy. You are also correct that it happens in other places too. Some people overuse it, though. They abstract out the construction of their objec…

You have to be more clear with your terminology. The thing you are talking about is called "Factory Method Pattern". Don't call it just "Factory Pattern" because it is not really a factory. Instead it uses a factory to achieve a very specific goal.

Re: Design Patterns – A comprehensible guide

#60

Post by js8 »

mavelikara wrote: post #51
js8 wrote: post #50

Earlier quoted context omitted.

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

> these are, unlike design patterns, very well-defined mathematical objects IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. OO design patterns do not have mathematical foundations, but that does not make them arcane or toxic. > you shouldn't use such a broad brush Probably not, I agree.

> IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field.

I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not.

It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions (too little bang for the buck). (The other two criticisms are lack of formal definition and lack of representation in the computer language.)

Post reply on HN