rudiHammad said:

ps: there are also youtube videos that prove earth is flat. Just saying…something to think about.

The same thing could be said about things written in books. Especially on topic as fuzzy as software design. This isn't exactly calculus we're dealing with. ?

SOLID isn't a scientific fact. It's a vague - and frequently poorly-taught, judging by how often I see people having to re-explain them - set of ideals for how software should be structured based on what some people who were prominent in the early '00s valued at the time. They're guidance, not rules that you have to follow, apart from perhaps on a few (misguided) software engineering exams. SOLID is fair game for rebuttal and if you don't find the principles helpful in your circumstances you are free - in fact, I encourage you - to discard them. I have found them helpful from time to time, personally, but I find they require some degree of exegesis to apply to the circumstances I usually find myself in - not exactly ideal in a guiding principle. I'm also not confident that reducing my values as a software engineer down to a mnemonic acronym is actually all that helpful, so I've resisted the urge to try to come up with a replacement for use in the times when I'm ignoring them.

You shouldn't treat the GOF or any other pattern book as a Bible, either - in fact, I very much discourage this, and the use of design patterns in your thinking while doing the actual design (using them to talk about your code after the fact is fine). I just pick on the GOF's terminology as much as I do because if we're going to be talking about GOF concepts, then we should be on the same page about what the authors meant.

rudiHammad said:
I encourage you to read books

I have. ?I increasingly find the ones you're citing unconvincing the more experience I gain in the software industry, and the video game industry in particular. Video games have their own context and requirements and SOLID was not invented in a gamedev context, but an enterprise software context. I have also come to see “pattern-think” - the structuring of software in terms of design patterns, as if they were LEGO elements to be clicked together - as problematic because it leads to overengineering and sometimes even magical thinking. You don't magically infuse your program with correctness by using the right design patterns. Just because a thing worked for someone else doesn't mean it'll work for you…

You can start by Design patterns head first, where it explain how every single solid principle is reflected in each pattern when applicable.

This does not mean design patterns were designed to follow SOLID. In fact, the GOF book came out in 1994. 6 years before Bob Martin's paper on the subject that introduced SOLID principles. Books of this sort are exactly the kind of “exegesis” I describe above. Looking for connections between things that were not intended to be connected, but accidentally reinforce each other. There are other paradigms than SOLID and there are other design patterns that emerge from the values that inform such paradigms.

I assume you haven't read that book, neither GOF, otherwise you would not have such little knowledge on how solid feed deeply the design patterns.

You assume poorly. In fact, I had to write an exam on design patterns for my undergrad. ?

I just hope new programmers dont actually believe some of the things you say, for their own good.

And I hope they think critically about your design patterns books and don't take them as the word of software God, for the same reason. The GOF in particular are frequently misunderstood to be saying “these are patterns you should be using” instead of what they actually said, which is “these are some patterns we repeatedly see other devs using.” Go back and re-read the forward to that book.

@rudihammad This is your very first day on the forum, and you've somehow managed to pick fights with old-timers who have been on the forums and making games for two decades.

I think it's best for you to just agree to disagree at this point.

Your original question, “what is the difference between the component pattern and the builder pattern” is more than answered, and we've left discussion about it long in the distance.

Interestingly, I did some further digging to refresh my memories of how the “builder” pattern is applied and it seems there are actually two versions of the builder pattern - one that assumes you have multiple builder implementations and a director, a separate class that encapsulates a commonly-used set of builder steps, and one that has the builder invoked directly by the user: https://softwareengineering.stackexchange.com/questions/345688/what-are-the-advantages-of-builder-pattern-of-gof​

The GoF Builder pattern is one of the less important patterns suggested in the Design Patterns book. I haven't seen applications of the pure GoF Builder pattern outside of parsers, document converts, or compilers. A builder-like API is often used to assemble immutable objects, but that ignores the flexibility of interchangeable concrete builders that the GoF envisioned.

The name “Builder Pattern” is now more commonly associated with Joshua Bloch's Builder Pattern, which intends to avoid the problem of too many constructor parameters. If not only applied to constructors but to other methods, this is technique also known as the Method Object Pattern.

The latter (simpler) definition is the more common nowadays and is certainly the version that I have the most experience with, and therefore had in mind in my initial reply to this thread. In fact, I don't think I've ever actually run into an abstract builder in production code, nor one that had a distinct “director” type ("director" functions, definitely), only purely concrete ones that act like “creation data” classes, so evidently I've filtered the full definition with reusable “directors” and multiple builder implementations out of mind, dismissed as probably useless most of the time, like most (dogmatically-implemented) design patterns…

But I would say that both of these and the spectrum between them are recognizable to me as “builder.” The full blown, IMO overengineered (?)version described in the GoF is just Bloch's version with more moving parts and customizability. A pattern not need be implemented exactly as in GoF (or any other pattern language) to be recognizable. Implementing GoF exactly all the time is how we get code overengineered to the point of incomprehensibility.