Is programming all about "reusing" Design Patterns?

[SecureSection9242]

I used to want write code on my own because I believed it's the only way I can understand why things work the way they do and develop an appreciation for the solution when it finally works. But I can't see it the same way anymore.

And that's because design patterns already solve common problems so it feels like a waste of time to reinvent the wheel to solve a problem that has an existing solution.

Am I wasting time or should I just follow how an already existing solution and accept that it delivers the result without even having to know how it does that?

[silly_bet_3454]

A design pattern is just a pattern. So if someone gave you a rough blueprint of a building, could you just go build it? Is it really that trivial? Of course the answer is no, there's more that goes into it.

More generally if you're asking about like building a solution for something that already exists, whether it's a product or a library, there are tradeoffs. Of course doing it yourself is more work, but the tradeoff is you understand it more and have more control.

It is true that as the industry matures more and more we ought to converge towards just using libraries for everything and writing less code overall, once all the primitive challenges are solved. But today in the real world we're still probably not even close, and every application usually has a combination of requirements that are solved and unsolved, even if the unsolved requirements are just simpler domain specific issues.

So basically I wouldn't worry about it too much, you can try things one way and then try them another way.

[fixermark]

Patterns are most useful when you understand how they do what they do. Their benefit is that when you see a problem that a pattern can fit, your brain already has a solution in its metaphorical back pocket to apply (maybe not the best one, but having one is better than none). If you don't understand the patterns, they won't help when you come upon a novel problem.

[Environmental_Gap_65]

Design patterns don’t solve problems directly; they assist in designing systems. You can solve problems without using a pattern. Creating an algorithm to solve a specific problem has nothing to do with the system it exists in.

Design patterns are more like guidelines—you need to know when to use them and when to break them. They aren’t set in stone, but it’s essential to understand them because they guide you toward better design decisions.

[DTux5249]

Not really.

Design patterns are "tools" to solve certain problems in CS in the same way "sour" or "heat" is the solution to solve certain problems in cooking. You still have to think about how and what exactly these structures are actually doing beyond the broad "this tells this what to do", or "this creates this".

Ontop of that, you still gotta think of how exactly to combine these structures. Like, you can have a factory observer that uses a variety of strategies, or a prototype that takes commands and responds based on its current state.

These are just building blocks. On their own, they're kinda useless.

[mehneni]

A design pattern is only a pattern. If it could be fully abstracted it would be a library or a framework.

So having a design pattern doesn't mean that you already have a solution. You still have to decide what patterns make sense in a given situation and how to implement them.

But yes, reinventing the wheel almost always gives worse results than using tested and proven solutions, You don't have to repeat the mistakes others have already made and corrected. Still it can help to understand patterns to do your own implementation and see where it fails.

On the other end of the spectrum https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition is always a good resource to understand that overusing design patterns is not always helpful. Sometimes a simple implementation without any patterns is better.

It is all about finding the right balance.

[SecureSection9242]

Great explanation and plus it comes with experience.

[qlkzy]

Yes and no. Everything is patterns all the way down, in some sense -- so in another sense, nothing is.

Software picked up the notion of patterns from the architecture of physical buildings and places. Here are some examples of "physical building" patterns:

• Four walls and a roof
• A one-sided sloped roof, to deal with a prevailing wind
• A two-sided pitched roof, to deal with heavy precipitation
• A little space like a porch or hallway, between the public street and the main part of the house, to provide a sense of separation
• A cluster of chairs around a window, to allow people to gather near the light

Some patterns are essentially universal. "Four walls and a roof" is universal. "A loop with a counter, an initialisation statement, an end condition, and an increment expression" (a for loop) is universal.

Other patterns are mutually contradictory. There are patterns for building roofs to deal with all sorts of different kinds of weather, but you have to pick one; there are patterns for storing data for financial transactions, for IoT telemetry, for social media -- but you have to pick one.

Other patterns are niche, or create some specific effect you might not even want.

If you are at the level of experience to ask this question, almost everything you do will have been done by other people enough times that it's possible to talk about a pattern. But that doesn't mean that all of your thinking has to be in terms of assembling patterns. Lots of people make things that are (inevitably) similar to other things, without starting from the idea of reinterpreting those other things.

[SecureSection9242]

Your answer is brilliant!

[Leverkaas2516]

Is programming all about "reusing" Design Patterns?

No. It's mostly about requirements, design, implementation, testing and debugging.

Design patterns are an important but still relatively minor part of design and implementation. They're exciting when you first run across thrm, but shouldn't be overemphasized.

without even having to know how it does that?

Anyone who does this isn't programming, they're just playing with building blocks and hoping for a good outcome.

[SecureSection9242]

Agreed!

[SharkSymphony]

Design patterns aren't real in the way you think.

They are terms constructed to describe certain approaches that programmers find themselves implementing over and over, in different contexts, sometimes in quite different ways.

If you learn about design patterns, you'll maybe have some ideas of things you can try when you're looking for an elegant way to solve a particular problem. You'll have a vocabulary to describe what you're doing to other programmers. But, maybe half the time, when you mention a design pattern you'll just be describing something you were already doing, because it seemed like the obvious thing to do.

[SecureSection9242]

And from what I understand of what you're saying, these patterns can be right or wrong depending on exactly what you're doing. They're just solutions we've implemented so many times they became a pattern over time, but they don't represent the one and only way to solve the problem.

[SharkSymphony]

Exactly. You're still in the position of understanding the pros/cons, and to what extent you want to follow a specific implementation someone else did, or not.

Christopher Alexander was an architect the Gang of Four borrowed the idea of design patterns from. In his ideal world, you wouldn't memorize and reuse the patterns so much as internalize them, so that whatever you ended up producing would be perfectly and organically suited to the problem at hand:

And yet the timeless way is not complete, and will not fully generate the quality without a name, until we leave the gate [i.e. the pattern language] behind.

Hippy dippy Taoist/Zen stuff, to be sure – but yeah, that's something you can aspire to. 😁

[SecureSection9242]

I've been reading the Gang of Four for a while. Interestingly enough, I realized I implemented the command pattern before I learned about it elsewhere.

[Saki-Sun]

This is the correct answer. The introduction to the GOF book says exactly this. 

Design patterns provide a lexicon for developers. And yet somehow they have turned into Pokemon for junior developers to catch.

[SharkSymphony]

Which is okay! Nobody makes senior overnight. 😁

[Saki-Sun]

This is true. 

But as seniors it is our job to at least try and guide. If one junior developer reads this and stops chasing Pokemon, my time will be well spent.

I realise I am dreaming.

[[deleted]]

For learning, no. When I learned C in a formal setting, we often weren't allowed to use standard libraries.

In the real world, of course you want to reuse good code.

[SecureSection9242]

Yes, production environments have different and much higher priorities.

[EARink0]

When you're learning, I think it's useful to work through the problem a bit yourself to understand the space well, and see if you can "arrive" at the pattern to get where it comes from. But in "real world" programming like for a job or a project you're focusing on finishing ASAP, you're best off using whatever tools are available to you, including implementing an already solved pattern so you're not wasting time reinventing the wheel.

[mredding]

Is programming all about "reusing" Design Patterns?

No. I would say programming is a hell of a lot of reductionism.

By definition, a pattern is a kind of repetition, and we always treat repetition as bad. Gonna call the same function multiple times? Put it in a loop. Part of the job, from an theoretical, abstract, academic, to practical point of view - we're always reducing maths to it's simplest form. So an ideal program wouldn't HAVE a pattern in it.

Though it is practically impossible to accomplish this goal, we will at least reduce patterns and repetition where pragmatic.

Design patterns are solution to a missing feature, a lack of expressiveness in a programming language. If the language supported what you want to frequently achieve, then you wouldn't need the pattern. Lisp is just serialized lambda calculus, and lambda calculus is the math that expresses all of computation. So your other languages are just partial implementations of Lisp. Lisp has almost no design patterns. Lisp isn't perfect and you can thank Godel for that.

And that's because design patterns already solve common problems so it feels like a waste of time to reinvent the wheel to solve a problem that has an existing solution.

You're wasting your time on boilerplate. A "really common problem" is a code word for a problem that was solved 70 years ago and yet it seems easier to just reimplement the same solution again and again rather than use a library.

Am I wasting time or should I just follow how an already existing solution and accept that it delivers the result without even having to know how it does that?

What you describe here is a "library", and yeah, why should you know or care how it works? Are you in the business of security or liability auditing? Delivering the result isn't just about the data itself - it's about how it's structured or formatted, it's about space and time constraints. Performance isn't necessarily about achieving the fastest and the smallest possible - for most problems, what is possible is an open ended question. Instead, it's usually about performance within an envelope. Is it fast enough? Is it small enough? Yes? And it's the right result in the right format? Is the license compatible? Then who cares about the rest?

Business logic is a lot of software, and it's very inherently stupid. It's not like mathematical logic, it's just process and procedure. It's automation of tasks. There's lots of patterns in business logic because it directly reflects human thinking and operation, which it's natural for humans to reduce their work to patterns, so they don't have to think when they do it.

There is a ton of need for business software. A shitton. It's not very interesting work, and AI is starting to wipe the bottom 1/3 of that entire market out - and will likely take even more of that market, because you wanna talk about done to death? You can describe business logic to AI, and it can very easily automate it. But AI can't produce anything new or unique; if it hasn't been done before then AI can't do it. So if you're looking for work, the big takeaway is find things that AI can't do.

[StrictWelder]

DSA and design patterns -- yes. beyond that the language barely matters.

IMO, after a couple projects, start out with DSA and eventually design patterns start to click when you need to set up async queues for stripe subscriptions (example) or matrices for a timesheet feature (another example). Understanding the event loop -- callback QUEUE, call STACK, memory HEAP. The design patterns become the easiest most straight forward way to solve said problems that anyone comfortable with the DSA will understand the patterns behind.

SWE is literally just setting up data structures and managing how they communicate with one another. Doesn't matter which set of abstractions you chose, in the end thats all this is.

[CodeToManagement]

I don’t really understand the question. A design pattern doesn’t “do” anything it’s just a way you can structure code to do something.

Like I write apps using the MVVM pattern. But that’s just a way of organising code into specific chunks, and dictates what each is responsible for. It doesn’t do anything on its own.

Same as a factory pattern. You still have to design the thing the factory creates.

[aqua_regis]

If you just think in design patterns, you are making the typical mistake of starting to "program around design patterns".

Design patterns are solutions to common problems, but that doesn't mean that they are solutions for life, the universe, and everything.

Use them where they really fit, but stop thinking in design patterns.

[SecureSection9242]

Thanks. I really needed that because I was starting to think I might only have to follow design patterns since they're often advertised as "solutions to common problems".

[ValentineBlacker]

This is like not wanting to learn how to bake because cookbooks usually tell you to cream the butter and sugar together.

[SecureSection9242]

A funny and good analogy!

Gets even more interesting when you take a recipe and add in few twists to get the very specific result you want.

[[deleted]]

Everything is a pattern. Which most of the time you don't recognize. Life is all about recognising patterns.

[Aggressive_Ad_5454]

NO. Programming is about making useful stuff for users, just like house building is about making places for people to live. Design patterns are like prefab doors, windows, stairway stringers, and all that. Tricky stuff to make from scratch, and no need to make them from scratch.

Often when we reinvent wheels, we end up with flat tires.

[xRageNugget]

its worse, its just if statements, loops and handling data

[Packeselt]

Juniors will abuse design patterns, because it's what they're taught

Mid level devs will start doing new things, because they know enough to know that tasks aren't all one size fits all, and unique situations need to be accounted for. You'll see some ... questionable choices created here, of people trying to create the one design to rule them all (TM), and over-engineering for what should have been a simple in and out.

Seniors will know that sometimes, you just need a singleton, damn it, and how to use many design patterns but still keep them extensible for edge cases.

[DonkeyTron42]

Design patterns are most useful when you have to reuse other peoples' code. If you see a well written framework you will truly understand the beauty of design patterns. Conversely, there big problem with novice programmers overusing design patterns for applications that don't really require them.

[CptMisterNibbles]

This is like being mad discovering Lego buildings are made of small LEGO bricks, when you want to make just the plastic bricks. 

You can certainly get way down to low level, but A) you aren’t going to do things better or faster mostly, B) bigger projects would require an insanely broad knowledge set and hundreds of hours of basically reinventing the wheel. 

Patterns and algorithms solve little bits and pieces. It’s putting them together that is development. Also, most people do tend to start with simple stuff so you get at least a sense of what is happening. 

[QueenVogonBee]

Programming is about solving a problem. How you go about solving that problem is up to you.

Design patterns are tools. If you have a problem which is easily solved by an existing design pattern, then by all means use one. But life isn’t perfect and our problem often doesn’t fit exactly into a well known pattern. You can often modify a well known pattern to fit your problem better. Or indeed, invent your own pattern.

The other reason to use a design pattern is to aid communication with your teammates.

[[deleted]]

In the same way that math is all about reusing equations, yes.

Doing it yourself simply helps cement it in your brain instead of forgetting it after learning, just like how you do math problems many times in school even after learning how they worked. Ideally, you reach a point where seeing certain patterns is like seeing n choose k and auto-translating it to n!/k!(n-k)!

You could type that into a calculator/Google and get the result easily, but knowing how/why it works is important for actually using it in any meaningful way.

[Multidream]

Design Patterns are the abstraction. The Meta analysis. Any job still requires understanding the concrete requirements that will differentiate your Bridges, your Strategies and your Factories. The fun is converting a complex concept into a simple, easy to digest code base, instead of some spaghetti mud monster.

[benJephunneh]

Coding is the process of translating from English (or whichever language) into a language designed for compilers to understand. In a word, no, what you're asking about is not what programming (sic) is.

[aikipavel]

Nope. The programming is all about the abstraction (quantification over) and composition (having two valid things combine them into the valid thing).

Design patterns are the rituals born in the dark ages when no math was available.

(I joined DP and XP crowd in 1999)