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

71–80 of 112 posts

Re: Design Patterns – A comprehensible guide

#71

Post by cmoscoso »

iak8god wrote: post #11
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…

I dislike OOP. It's my least favorite paradigm. The "objects-first" approach to teaching programming was such a bad idea. All that said, there is a place for OOP. And while a world without OOP would be a better place than a world without FP (if we had to choose), I think you'll be waiting a looong time for that world to materialize.

That world is already here, just not evenly distributed.

Re: Design Patterns – A comprehensible guide

#72

Post by thom »

js8 wrote: post #67
thom wrote: post #65

Earlier quoted context omitted.

This is, and always has been, a poor criticism of design patterns, by people who think they're just a library of code that idiots are supposed to cut and paste to be better programmers. A common example from the GoF book is the Strategy pattern - most functional programming snarks will jump in and say you don't need this! We have first class functions you can pass around! And it's entirely true that an implementation…

My main point (just to make sure we are on the same page) was that whatever patterns are, we should also tell computers "look, here I use this pattern", and not rely just on humans to see it. Unfortunately, computers are idiot savants, so this very well might require those to be formally defined. Anyway, I think we have an ontological disagreement here. I don't believe the "design patterns" which cannot be formally d…

But you don't _talk_ exclusively in formalisms to other mathemeticians, do you? You don't immediately jump into a specific form of calculus upon first hearing of a concrete real world problem?

And I'm not saying React itself is a pattern. I'm saying if you wanted to create your own React-like framework, or to communicate the design decisions and mechanisms that make it different from other frameworks, there is value in extracting and naming those concepts. This way, people can appreciate, understand, compare and contrast them _outside_ the context of one piece of concrete reusable code. As an entirely throwaway and unthought-out example, you might say 'Differential Rendering' is philosophically different to a 'Mutable Document'.

But if you think all things in the design of software are reducable to reusable pieces of code, more power to you.

Re: Design Patterns – A comprehensible guide

#73

Post by yoodenvranx »

mikekchar wrote: post #66
yoodenvranx wrote: post #59

Earlier quoted context omitted.

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.

No it's an "Abstract Factory Pattern", but clearly I did not succeed in describing my use case adequately ;-).

The Abstract Factory Pattern is one of those patterns which I never fully understood because I never found a good real-world example which relates to my line of work. That's the reason why I misunderstood you ;)

Re: Design Patterns – A comprehensible guide

#74

Post by opk »

yoodenvranx wrote: post #58
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.

I don't really see what you call a "Simple Factory" as being covered in the Gang of four book. I should have been clear about meaning Factory Method but the terminology is often apparent in class naming. So for the "Abstract Factory" pattern, I would use "Kit" in class naming. I would reserve "Factory" for the "Factory Method" pattern. Pointlessly wrapping constructors in a separate class and calling it a factory doesn't really get you anything. Neither does contriving a parallel hierarchy to pointlessly allow the use of the "Factory Method" pattern - something that I have also seen.

Re: Design Patterns – A comprehensible guide

#75

Post by qznc »

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 also do not understand "parallel class hierarchies".

Here is another use case for a factory: Building an AST data structure in a compiler. There are nodes to represent Constants, Addition, FunctionCalls, etc and you have to build a tree structure, which represents a program.

Now consider the case, where you build the addition of two constants ("36 + 6"). Using constructors, it could like like: new Add(new Const("36"), new Const("6"));

Using a factory: f.newAdd(f.newConst("36"), f.newConst("6"))

The advantage of the factory is that it can optimize on the fly and return a Const("42") node instead of an Add.

Re: Design Patterns – A comprehensible guide

#76

Post by catshirt »

dang wrote: post #41
catshirt wrote: post #15

Earlier quoted context omitted.

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.

so, if i'd noticed you were dang before i responded i probably wouldn't have. only because i was trying to form a consensus. i didn't realize the consensus was being explained to me. :)

Re: Design Patterns – A comprehensible guide

#77

Post by Sir_Cmpwn »

callumprentice wrote: post #8
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.

Reminds me of physics books from college where they might say "a horse is approaching a barn door at relativist speeds..." - always seemed much too contrived and I'd maybe have preferred "an exotic particle is moving towards an electron at...".

The physical behavior of a horse is better understood than that of an electron and might make it easier to consider the subject at hand, though. We know what path the horse will travel and we know that when the horse reaches the barn, it will go splat (well, in this case the barn will go splat). There are several competing theories that could describe what happens with the electron and the exotic particle, though.

Also, it's fun to picture a horse travelling at relatavistic speeds :)

Re: Design Patterns – A comprehensible guide

#78

Post by asitdhal »

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.

That's why GoF book is available in the library.

People write more concrete tutorials and publish online. Abstract literature is for researchers and Concrete literature is for people who need a quick solution.

Re: Design Patterns – A comprehensible guide

#79

Post by morbidhawk »

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.

In addition to contrived examples impairing comprehension I even think a real-world example fails to help the reader capture the most important piece of information about design patterns, and that's the context around when to use them. Giving a worked-out example while teaching the concept has the limitation that the reader didn't discover the pattern themselves in code, instead it was ripped out of a code base and handed to them without context of its use. And instead of seeing it as an option that was selected to be used in a particular code scenario it is instead presented as a fully-worked solution that can be plugged in anywhere and describing when to use it in words isn't as effective as discovering it being used in a code base you've been learning from.

Quite frankly, in my radical opinion, I think learning about programming through reading about it (books, articles, blog posts, etc) isn't very useful once you are past being a beginning programmer. To be a better programmer reading code is the only way I've seen good progress with learning new abilities that don't cause me to over-engineer my own solutions. This might not work for everyone but for me reading code daily has been a silver bullet to programming knowledge that a book or design pattern article could never capture for me.

Re: Design Patterns – A comprehensible guide

#80

Post by cessor »

js8 wrote: post #61

In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps, or GOTOs (as they were colloquially called). And they had a very influential programming book, called "GOTO design patterns". Here's a few examples of design patterns from the book: - "IF pattern" - If you need to execute code only if some condition is true,…

> "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?"

I often asked myself this question! Why do I have to say

    public class DatabaseConnectionSingleton {
        public static DatabaseConnectionSingleton getInstance (){ ... };
    }
and then get an object using:

    var db = DatabaseConnectionSingleton.getInstance();
Why can't I say

    public singleton DatabaseConnection {...}
and just go

    var db = new DatabaseConnection();
and let my runtime make sure that I get the appropriate instance? Left aside the discussion of how useful that pattern is, I would like my language to be more powerful. I am aware of alternatives (Borgs in Python) and that many people consider Singletons an antipattern, as it helps introduce globally shared state, etc. but then, why do I have to care about how instances are implemented?

After all, in C#, foreach interacts with iterators, why not push other mechanisms down into the language in the same way?

Ideas:

    // Unit of work, commits changes before the reference gets removed from stack
    public unit CustomerForm { } 

    // There can be only one.
    public singleton DatabaseConnectionHighlander {}

    // Any method called updates values in some way
    public builder QueryString {}
Post reply on HN