Hacker News new | past | comments | ask | show | jobs | submit login
Design patterns let you apply existing solutions to your code (stackoverflow.blog)
52 points by skellertor 1 day ago | hide | past | favorite | 58 comments





I believe thinking of design patterns as something you "use" is one of the biggest mistakes being marketed to new programmers. A lot of them are niche use or only really exist to cover lack of features in languages, such as the Singleton pattern that has no real use in Cpp because you can just put a global pointer instead. It makes people think more about the code than about the problem they are trying to solve to begin with and often ends with a lot more code than is needed to solve the problem for no real good reason. Ive seen a lot of young programmers being mislead considerably by articles like this, including myself.

I see design patterns books and articles as more of a bestiary than a toolkit. Their purpose is not to be a repository of prebuilt solutions (because patterns dont solve anything by themselves). Their main purpose is to give names to a good amount of very common code patterns so you can communicate about it with other programmers.


I can't agree more. Design pattern resources often omit the fact that "design patterns are missing features of programming languages". It's not a piece of common knowledge yet (at least outside HN), and I hope people could talk about this more.

Take the visitor pattern as an example: Say we have M types, and each type has N operations. OO languages like Java are good at extending M - you add another class. But it sucks at extending N because the obvious way is to add the operation as a method in every type. Visitor pattern helps you invert the problem, make it easier to extend N while suck at extending M. In fact, the visitor pattern feels more or less like it reinvented the plain, old "function" - just write a function and handle each type in it and you just achieved the same things.

I find it's always more readable when I just use a function. There's no exhaustive type checking so it makes sense to use the visitor pattern in Java, but I often people still use the pattern in, say, TypeScript without a second thought.

What if we want to extend M and N at the same time? There's a sophisticated design pattern called object algebra [0]. In this case, it's pretty clear that features like type class in Haskell and traits in Rust could solve the problem in straightforward ways without wrestling it with design patterns.

[0] https://en.wikipedia.org/wiki/Expression_problem#Problem_Sol...


> A lot of them are niche use or only really exist to cover lack of features in languages (...)

This take is a reflection of a failure to understand the concept of design patterns, their usefulness, and their role in software engineering.

Design patterns are not features missing from a toolkit or language. This is perhaps the biggest miscomprehension regarding design patterns. It's immaterial if a language supports or not a given programming construct in it's core language or standard library. The whole point of design patterns is that they represent higher-level programming constructs that pop up often in implementations and are frequently used to address common problems.

Think about it for a second: do futures or promises or callbacks or sharex pointers cease to be design patterns or lose any usefulness if these features are supported by the core language? Is the observer pattern not a design pattern anymore in C# or Java once it was implemented into them as first/second class citizens?

Or do we understand what these techniques involve just by mentioning these keywords?

Clearly the main problem plaguing design patterns are those who feel entitled to criticize things they don't know and clearly failed to grasp even the basics.


>Design patterns are not features missing from a toolkit or language. This is perhaps the biggest miscomprehension regarding design patterns.

It's relatively popular opinion that some design patterns are used because some languages lack some features that can achieve similar stuff in "better" way.

So what's design pattern in your opinion?

For me design pattern is just approach to some specific problem, very often connected with some $implementation_example in order to communicate more effectively.

Design pattern's purpose is to improve communication by naming solutions to "common" problems.


> It's relatively popular opinion that some design patterns are used because some languages lack some features that can achieve similar stuff in "better" way.

You're confusing a couple of unrelated issues there. Just because you need to implement a design pattern if you want to use it with a language/framework that doesn't provide it's own implementation, quite obviously that does not mean that design patterns only exist if you implement them yourself. That's a terribly silly misconception, and demonstrates a misunderstanding of the very basics of what a design pattern is.

Just to be absolutely clear, even Wikipedia defines design patterns as "a general, reusable solution to a commonly occurring problem within a given context in software design", and a "description or template for how to solve a problem that can be used in many different situations." What exactly is there in the definition that ties this to an implementation?


>What exactly is there in the definition that ties this to an implementation?

In definition nothing, but I believe there are very popular implementations (mostly one) of given design pattern that people are aware of and associate with given design pattern

and I guess it may kinda improve communication? idk.



Nah, design patterns are mostly communication tools.

When you name something "factory", when some doc mentions "dependency injection", when you import a "register", when you talk with a colleague about a "decodator", if you know the name, you already know what it does, and what the API will probably look like.

I say probably, because we don't have a format definition of all design patterns, nor are they all recognized as such. For for the ones that are and we do, we don't all agree. Not to mention you must adapt them to problems and languages.

So sure, when you code and you encounter a problem, you may use a design pattern. But you don't explicitly do so. Just like a chess master doesn't chose a move by thinking "I'm going to use x", they just decide on it, and also adapt it to the situation.

I never think about design patterns when I code, only when I name the code, I write the doc, and talk about it. When I communicate.

If you read a book about design patterns, they will make no sense to you. You will probably misuse them. But if you look at real life source codes from other devs, or yours again and again, you realize some problems come back often, and a lot of people use similar solutions. Then you look it up: bingo, it has a name.

That's how it works, not the other way around. It's formalization of real life, not theory to apply.


> Just like a chess master doesn't chose a move by thinking "I'm going to use x", they just decide on it, and also adapt it to the situation.

This is an interesting analogy maybe someone who knows more about chess can correct me, but don’t chess masters have elaborate memorized openings and end games where they do decide to use “the indian defense” then go on autopilot until someone deviates from the common lines?


The idea is that they won't tell themself, "I'm going to use the indian defense".

Just like I won't tell myself "I'm going to apply the strategy pattern here".

We just see the situation, and if it calls from a solution from the banks of solutions we have encountered in the past, we see if it fits, we try to apply it if it does (tailoring may be necessary).

Then the commentator later may say "oh, he decided to use Y". But that's for the benefits of the people watching.


I'm largely agreed with this, but to add on:

if you consider the idea source -- Alexander's A Pattern Language -- the notion of a pattern is a more useful than that; it is both a communication tool, as well as the realization that the problem (in his case, buildings) can be subdivided into smaller parts, and at a certain level, these parts fall into common repeating forms (patterns). You can thus mostly initialize the design by simply composing patterns together.

The key that typically gets lost in GoF pattern discussions is that it doesn't end there. Once the patterns are decided, you need to account for the non-standard details of the problem at hand -- e.g. the house is partly on a hill. The hill raises the height of the door. The door had a relationship with the window -- it's no longer aligned, and will have to be modified to fit. With the shift of the window, the mirrors need to change.. and with the mirrors, the door. Eventually these changes will stabilize, producing an equilibrium (TB: he declares that equilibrium to be "beauty", and a feature that everyone can innately detect, though they may not know how to reach it... this corresponds strongly to "code smell" or "elegance" in programming)

So the elements of the home starts as patterns, but they're also in a fluid state, and the effects of reality will trigger a feedback loop, creating continuous design reflows, until the whole thing reaches an equilibrium (and you can now build the house).

He then goes on to note that the home exists in a continuously fluid state (as it's used and changed by inhabitants), constantly deviating from that equilibrium, and being brought back into that state. So the most beautiful homes are those not designed into a harmonious state, but maintained in a harmonious state -- I particularly like the correspondence to programming here.


Yes, but even after the opening lines are exhausted, a huge part of expert chess play is just intuition and choosing which moves “look right”, rather than conscious thought and calculation (though that too has its place).

The equivalent of a standard chess opening would be a function call or some form of template in software engineering.

I always give my students these to read when I teach design patterns :-) https://realtimecollisiondetection.net/blog/?p=44 http://realtimecollisiondetection.net/blog/?p=81 "The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades."

Just noting that the author’s book (Real-time Collision Detection) is an incredibly well-written technical resource and is a good read for anyone trying to implement their collision detection in their game or physics engine.

this is a fancy argument but it doesn't fit reality. A good chunk of problem solving is breaking them down and rcognizing what is already solved so you can solve what isn't. If there are lecturers out there teaching students that software engineering is a some sort of "creative endeavour" where you constantly invent new things at all time then that's actually a danger to society.

I teach students who write code for VFX software, Simulations and Games so it is a "creative endeavour" :-)

The problem with design patterns is that it's far too easy to "apply existing solutions" to problems that don't exist.

Design patterns can definitely be useful, but only when used sparingly and if they really are the simplest solution to the problem. When applied just for the sake of "best practices" without really looking at the problem, all they do is create a new problem.


I could not have stated it any better. If I see code with GoF "Design Patterns" by junior engineers, I already know I will have a not-very-fun time ahead digging through layers of boilerplate that all the design patterns managed to obscure.

The other danger here is that especially the GoF patterns have often times succeeded their own usefulness with the introduction of closures, first-party functions, enums and option types to the languages. And some (like Singletons) are clearly harmful these days.


I hate this "argument":

> The problem with design patterns is that it's far too easy to "apply existing solutions" to problems that don't exist.

If you use "something" (in this case design patterns) wrongly, it's not "something"'s fault. It's like saying there's something wrong with the car if you are drunk, speeding and crash it.


> The problem with design patterns is that it's far too easy to "apply existing solutions" to problems that don't exist.

That's not a design patterns problem. At most, that's an abstraction layer problem/YAGNI.

> Design patterns can definitely be useful, but only when used sparingly and if they really are the simplest solution to the problem.

This statement reflects that the whole point of design patterns was completely missed. Design patterns are not pre-baked solutions. They are higher-level coding constructs that reflect specific concepts, and thus provide an ubiquitous language for developers to describe and discuss what they are doing without resorting to ad-hoc terms and definitions. Programming constructs, like callbacks, promises, futures, dependency injection, singletons, etc, don't lose their importance, usefulness or value if they are covered in a GoF-type book or if they are implemented by a library.


You are right that this is not a problem with design patterns themselve.

It's how some people tend to use them when they are not necessary or a simpler solution would have sufficed. This I believe was OP's point.


> It's how some people tend to use them when they are not necessary or a simpler solution would have sufficed. This I believe was OP's point.

Yeah you are right, YAGNI is indeed not taken into account enough. However, blaming design patterns not only misses the whole point and shows a lack of understanding regarding what design patterns are and how/why they are used. In fact, I would go as far as claiming that complaining about design patterns is a symptom of limited technical knowledge and experience, and the bulk of the typical anti-design pattern cliches are just the defense mechanism kicking in within the spirit of the "fox and the grapes" fable.


It seems that the only people who can use design patterns correctly are the people who are experienced enough not to really need them.

Yeah, this is the same conclusion that I have reached. There's nothing wrong with design patterns. There's nothing wrong with language features. But you want to use the correct tool for the job. And for some reason with design patterns, the framing of simplicity among the so-called experts about when to use that tool is missing, so they are used improperly.

What's the correct tool? The simplest tool that can get the job done, the Principle of Least Power[0]. We often hear "Favor Composition over Inheritence", but never "These are the instances where Composition does not work, and Inheritence needs to be used instead."[1] Rich Hickey's "Simple Made Easy" shows many more examples, but this principle is very wide reaching. Prefer expressions over code blocks. Prefer for over while. Prefer map over for. Prefer data over functions. Prefer functions over macros. Prefer monoliths over micro-services. Prefer unikernels over containers. Prefer smaller teams over bigger teams.

For the monolith vs micro-service, it's better to have a separate micro-service than a spaghetti monolith, but if you can un-spaghetti your monolith it will be simpler. It might not be easier. It might not be possible for your team based on the difficulty of the task. Likewise for team size, smaller is better, but only if that team size has all of the required skills. If they do not, grow the team or train your team.

The left side is simpler, and therefore composes better. If you need more power, by all means use it. If you are designing a system, always make the left easy, and the right ever so slightly annoying. Nudge people into the Pit of Success[2].

[0]: https://blog.codinghorror.com/the-principle-of-least-power/

[1]: I believe the answer is that composition always works if you have access to all of the code, and inheritance is a back-up if you are using a library you can't change. I might have a

[2]: https://blog.codinghorror.com/falling-into-the-pit-of-succes...


When looking at the GoF design patterns, I believe one should also note that they were created not only to solve a bunch of design problems, but also to deal with the limitations of the programming languages back in the day. For example, if you learn about them in the Java context, they make perfect sense as they are well aligned with the language features required to implement them. Try however putting them in Python context and they often result in unnecessary complexity.

You can actually see this in the article. The Python examples are awful (not very idiomatic). This is just Java written in Python, even with non-Pythonic camelCase naming.


Python is four years older than Java, and both have been extended a great deal since their inception.

The original Design Patterns book was written with Smalltalk in mind, which was dynamically duck typed, and had functional features (code blocks), among other things that didn't come to Java or Python for almost a decade.

Perhaps some language features are comparable to and negate the need for some design patterns, like Visitor with multiple dispatch which is provided by Julia --- but most creational, and behavioral design patterns are more just techniques that are independent of most languages and language features.

I definitely dislike the flavor of these articles that paint design patterns as a toolkit to piece together to build programs, rather than recognized components of a sound architecture which can help you build and design software that can be more easily reasoned about and extended.

It does lend to people making rube-goldbergesque monstrosities without really thinking about the why behind the way they are doing things.

I do think there are patterns I have recognized while programming in Rust, Ocaml, and a number of other languages, which never have had a description lent to them; and it's nice to see design patterns being talked about again, beyond the hype of the 1990's.


> … written with Smalltalk in mind…

"Since we must eventually implement our designs, a design pattern also provides sample C++ and (sometimes) Smalltalk code to illustrate an implementation."

Chapter 1. Introduction. "Design Patterns: Elements of Reusable Object-Oriented Software"

https://www.google.com/books/edition/_/6oHuKQe3TjQC


In software engineering certain ideas that sound neat can undeservingly gain a lot of popularity and endorsment. OO and design patterns are among those ideas. The promise is tempting - we'll give you a template to solve problems, and that will prepare you for most of the situatuons that you encounter. This appeals to inexperienced programmers who don't know how to approach real-world tasks.

The idea will probably remain popular as long as programming is a thing, with an ecosystem of blog posts, tech talks and expert books to grant it credibility.

But let me tell you this: there are principal engineers at FAANGs that wouldn't be able to name more than one design pattern (the one being Singleton).

DP might help in your career, but only if your bosses also believe in them. Many things in our profession are based purely on belief.


Let me begin with saying I'm happy the design pattern fetishism of the 90's is long dead. But that I think the pendulum has swung the other direction a bit too far to say the promise of OOP and design patterns is somehow a failed avenue only practiced by inexperienced engineers.

It's hard for me to understand this perspective when a large portion of the foundation of modern software is built on OOP and design patterns.

If you crack open the Chromium source code, you're going to see Factory mentioned hundreds of times: https://github.com/chromium/chromium/search?q=factory

As well as singleton: https://github.com/chromium/chromium/search?q=singleton

Visitor: https://github.com/chromium/chromium/search?q=visitor

And the list goes on, and on.

This is true for V8, which underlies NodeJS, and is the engine that powers most modern JavaScript:

https://github.com/v8/v8/search?q=factory

V8 was designed by the same engineers who built the Java Virtual Machine, and what techniques did they employ to build this massive piece of software that runs the modern web? Object oriented design, and design patterns.

It's very probable people designing modern web applications for the FAANGs are not particularly aware of design patterns, or even maybe that MVC is a design pattern even if they are using it. It's possible many design patterns aren't useful for the types of problems they are solving, or could complicate matters if they used them haphazardly.

But the engine driving every single JavaScript program, is built on top of a behemoth of object oriented, design pattern laden, software, written by FAANG engineers that I promise you understand design patterns extremely well.

I'm not saying this is the end all, be all, of software design. Or that "modern" functional takes on software design (most functional languages and ideas predate OOP) aren't perfectly valid, or successful. Or even that they couldn't solve many of these problems.

I'm just contesting any dogmatic rejection of what has actually been one of the most successful branches of software design.


"Design patterns are bug reports against your programming language." - Peter Norvig, https://norvig.com/design-patterns/

I have to say that I agree with this. In my experience design patterns in Java lead to overly complicated, over-engineered code, think abstract factory factory factory. I've seen it and had it described as "best practice", decoupling, design patterns, etc.


I've seen too many examples of code at work where you can tell a developer has just come back from a training course on design patterns. It's usually an overly complicated solution / 'pattern' that has been applied to solve a simple problem, because you've learnt these things right, so you should use them where you can. Rather than sticking to the simplest solution. Less code == easier to understand (for yourself _and_ others that will have to maintain your code) == less chance of bugs slipping in.

It starts with the Singleton and vaguely hints that it has some drawbacks. Why start with that, then? And why not flat our recognise that it is understood more as an anti-pattern these days?

I don't get blogs like these. This story has been told a million times with more or less the same content and structure.


> It starts with the Singleton and vaguely hints that it has some drawbacks. Why start with that, then? And why not flat our recognise that it is understood more as an anti-pattern these days?

There might be significant tradeoffs with singletons, but I wouldn't go as far as claiming they are an anti-pattern. Far from it. Managing and sharing a single instance across the whole application is a critical part of other basic software architecture constructs like dependency injection or even handing app settings.


You misunderstood the singlenton pattern. It's not about "Managing and sharing a single instance", it's about only being able to instantiate one instance of a class. That's not the same, because you can achieve the former without having the latter.

I agree that it is an antipattern.


> You misunderstood the singlenton pattern. It's not about "Managing and sharing a single instance", it's about only being able to instantiate one instance of a class.

Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.

To illustrate your misconception, you can instantiate a regular class as a global variable and specify that no other instance is allowed in a project in the project's coding standards to enforce this at the code review level, and you still have a singleton.

The whole point of a singleton is that only one instance of a class is used across the system, regardless of whether this is enforced by any technice or not.

Don't confuse a specific implementation with the purpose, and requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.


> ...requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.

I'll disagree. There are very few situations where restricting class instantiation to one object both solves a problem and doesn't cause unneeded headaches.

Almost always a boring global with careful access control is better. It provides a single object just as well without limiting options for future software engineering needs: testing, adding construction parameters, migration, gradual deprecation, etc.

As to legitimate uses, anything with system scope can't be controlled within a process. And there are few things that inherently couldn't be instantiated twice that aren't better managed by the OS.


> a boring global with careful access control

There is no such thing as "access control to global", unless you mean humans in code review, in that case, OK


You can have global linkage and private access control in several ways.

> Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.

Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance." (https://en.wikipedia.org/wiki/Singleton_pattern)

And it's the same in most other definitions.

Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern, because again, it's not about just having one instance of a type/class.


> Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance."

Yes, I did. I also know what a singleton is, and the whole point it's a thing. Did you read my explanation were I pointed out your misconceptions?

> Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern,

You should first take your own advice into consideration and first read your sources before citing them. If you did before succumbing to your appeal to authority, you would have noticed the fact that your whole argument that singletons supposedly were an anti-pattern is what, and I quote, "it is frequently used in scenarios where it is not beneficial" because of the global state. Do you understand the problem with the way you're trying to generalize an assertion, specially given that enforcing a global state is often the whole point of using a singleton? If you fail to understand how/why/when a technique is used, that does not make it an anti-pattern.

Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.


We are talking about design patterns here, about the singleton design pattern. And not just about singleton objects. You still seem to mix up the two things.

> Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.

I think you are just misunderstanding me (and the OP) and I'm trying to clarify. I don't see which principle I would violate with that.


> We are talking about design patterns here, about the singleton design pattern.

I appreciate your attempt to move the goal post and gaslight, but it's already readily apparent that you're very confident in your misunderstanding and misconceptions, and very resilient to their clarifications and corrections. You're free to learn about the basics of design patterns if you'd like but until then I see no point in continuing this discussion.


> I don't get blogs like these. This story has been told a million times with more or less the same content and structure.

Yes, but things like this need to be repeated every few years to show it to a new generation of coders.

30-40 some year olds of today have probably been exposed to the original design patterns book already, but a younger generation grew up and worked with different tech, e.g. ruby / python / php, where these design patterns were reinvented.

I mean Ruby on Rails and some PHP frameworks from the 2000's / 2010's reinvented the MVC framework / design pattern, I had never heard of it before until these came back with it, but it's a pattern from the 70's apparently.


Probably because it's the most well known and understood designa pattern. The second one is probably Factory.

The authors of "Design Patterns" didn't create anything new, they just documented common patterns used in the industry and gave them a name. So, when you say "I used X pattern here", I can have a high level architecture of the code in my mind when navigating it and how it's supposed to work.

You should read the title as "Design Patterns for Java". You can try to implement the patterns in other languages and it may work but, if it doesn't, that doesn't mean the book is useless, it just doesn't fit your language of choice.

I believe someone would've written a book similar to "Design Patterns" at some point in time. It just happened to be the GoF.

You can say whatever you want, but today we all use patterns to talk about software. It may or may not be thanks to the book. We'll never know.


I've recently programmed quite a lot using 'Visitor'. But looking at my code a few months later it seemed hard to understand. Why? I think it is because the abstraction level is too high. The names in the code don't refer to anything that has to do with the problem the code is trying to solve.

For instance I needed to traverse some directories and do something with the files and subdirs in them. So I used my parametric Visitor class.

But when I now read that code it has calls to visit() etc. and when I debug the code it never mentions 'files' and 'folders'. That has been abstracted away into parameters. And that makes it difficult to understand what the code is actually doing, what it is accomplishing.

So, I've found it gets easier if I rewrite the code to use the vocabulary of the problem domain. It still follows the same (Visitor-) "pattern". The pattern is there but code does not use the vocabulary of the pattern, but of the concrete things it is dealing with.

And maybe that's why Design Patterns are important. Not as a code-library but as explanations of "patterns" that are useful when writing software.


Naming in a certain way is mostly for explanatory reasons in the tutorials and minimally for actual code. I just name the top one Visitorxxx and the rest as per their actual function. And when reading about them I also could not remember until using them multiple times. But at the end of the day, you learn each one, and then don’t need to remember how the respective parts of the code work. Else after a few months I would need to go line by line of probably worse code, unless in a happy accident I had reinvented them.

Good design and OOP avoids using GoF patterns while coding for many reasons. One is that they do not map well to the domain and the other is they are difficult to TDD or test. They are really tough to use too if you plan to publish your lib as an API.

The reason GoF got so popular is because for anyone struggling with OO principles it was easy to understand and apply. I hope for a better way to teach design by not using patterns.


> Good design and OOP avoids using GoF patterns while coding for many reasons.

I'm sorry but this assertion is not only patently wrong but it also makes absolutely no sense at all. Whether you know it or not, design patterns are pervasive and sometimes even the central selling point of frameworks or even runtime environments. For example, one of javascript's central features and selling points is it's use of an event loop (a design pattern) and extensive use of callbacks (another design pattern) and also promises (another design pattern). Ever heard of a worker process? That's also a component of a design pattern. What about futures, promises? What about shared pointers? What about observables? What about MVC? Data transfer objects? Active records? All design patterns.

> The reason GoF got so popular is because for anyone struggling with OO principles it was easy to understand and apply.

No, not really. The true value of the GoF book, and others like it, is that it documented widely used design patterns and thus enabled an ubiquitous language to form.


Thanks for the references. Apologies for not explaining that well.

I wasn't generalising about all patterns rather about using GoF patterns with a cookie cutter approach. Atleast, I am sure made that mistake.


(design) patterns are an initial step in the process of automating the automation.

You, the automation engineer (programmer) notice you are using the same way of solving a thing and the code of the solution at all occurrences looks somewhat similar. Well, we are no longer writing in machine code and have subroutines and functions. So you go ahead and turn the pattern into a function of your language has them. Sometimes a function is not enough, but fortunately we have macros. At least some languages do. For the unfortunate ones with less powerful languages you have to keep it at the pattern stage and never evolve to reduce the boilerplate or automate your job away.

For this reason design patterns are often called the "missing language features". Which you can never understand until you have touched the powerful languages with metaprogramming capabilities.

Now, there are situations in which design patterns have to be used because they are applied at a cross section between systems. There is no single language encompassing your entire code, but many languages for many systems. Unless you go crazy with string templating (ie. inventing a new poor man's language), you will not be able to move beyond the pattern stage. On the other hand, a repeated instance of the problem between systems suggests there could exist a language that many people would use. The problem was repeated after all.

This usually gets resolved by a simple system integration engine, which is operated through some json, xml or yaml configuration file. Eventually there comes a need to introduce variables, file includes, loops, etc.

http://mikehadlow.blogspot.com/2012/05/configuration-complex...

People turn to become 'advanced yaml engineers', like now in the k8s world, for what perhaps could be managed by programming language.

After many frustrations, eventually a new special purpose language will be built for it.

Long lasting design patterns in the codebase are pointing at missing language features. Or at a new programming language at the horizon.


They also let you import existing problems into your code.

The design patterns as defined by the book "Design Patterns" seem to be closely-coupled to the implementation language. This presents them more as cookbook recipes and less as patterns.

It would help if the design patterns could be defined per language and written in the language's own idioms.


> Design patterns are solutions to commonly occurring design problems in developing flexible software using object-oriented programming.

This completely misses the point. You don't "pick a pattern" and choose to apply it.

Design patterns are a way to take your best solution and describe how it works to other programmers.

For example you might say something like: "We used a singleton here because we can barely manage to get one instance working correctly and never intend to write tests".


You're right, though I think casual uses of factory methods or objects is a tidier example. Especially since you don't have to justify it with hand waving about bad code.

A nice presentation, but which are the most common design patterns? Are those in the article? I would also rank high e.g. Observer. Also some toy real world examples are common in those sort of presentations for a more complete understanding. In relation to other articles this gives better intuitions on where they are used.

design patterns create impression that it is possible to and naturally encourage to piecemeal substitute the system level understanding with the understanding of the local behavior. I've seen such software projects many times - beautiful patterns everywhere, you can teach students using that project, and the only "minor" defect is that the software is extremely buggy and slow, the better patterned/architected - the slower&buggier.

No wonder it is so beloved by all those enterprise architects - it allows to "architect" without actually architecting, like building a bridge without an overall bridge plan and calculations, only with the plans of its components and just piling, "injecting" and smashing these components together.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: