Hacker News Reader

Comment by TillE | Hacker News Reader

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.

View on HN

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

I know I might be in the minority, but this kind of stuff doesn't bother me at all. The silly abstraction is essentially there to highlight which part of the problem / lesson you should be focusing on, and to stop you from going off on a tangent and getting bogged down in the gritty details.

Going with your exotic particle example, once they've framed the problem like that, there's an implied expectation of reality and correctness which is likely going to be missing from an introductory example.

Check out Soviet books. You don't get the feeling the authors assume you're mentally challenged as you do in most other books.

This is all fun, but I think knowing how to apply knowledge is an important part. Many don't have a problem with electrons and pulleys, but put a real world example and they're out of their wits compared to someone who uses to dead reckoning.

https://mirtitles.org/

There's an interesting book on the site by Belikov: "General Methods for Solving Physics Problems".

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

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.

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.

Be careful what you wish for. We can always take the "zoo animals with varying legs" classes and interfaces out of the box again.

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

I'd say when I was first learning about many of the design patterns, this was my biggest hurdle as well. The examples and analogies were unrelated to real-world scenarios and didn't do much to help me understand the concepts.

It wasn't until I came up with my own real-world examples that were specific to my domain and really applied the design patterns in practice that I really started to understand everything. I don't think it's really the real-world example that helped so much as the actual process it took to arrive at an implementation.

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

Disclaimer: I haven't looked at it in many years, but I seem to recall Fowler's Enterprise Patterns[1], while covering a higher layer of abstraction, grounded in real world problems.

[1] https://www.martinfowler.com/articles/enterprisePatterns.htm...

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.

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

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.

Reply on news.ycombinator.com