rudiHammad said: If you didn't read GOF, I recomend you read it.
While the image you posted says the word “Director” on it, Oberon is correct that it's not a design pattern in the book. It is used ONLY on that picture on page 98 that you linked to, and in the description for the image describing what they meant for each thing on the image. “Director - constructs an object using the Builder interface."
Perhaps you would be better rereading it?
In either event, it seems that you're focusing far too much on the academic study and what a book says or a website says.
@frob i neveeeer said it was a pattern. Pehaps you would reread my reply?
I guess me saying this in the previous reply: Hey guys, at no point I said Director is a pattern. It might have look like that because how I quoted it. Director is a Participant of the builder pattern. was not clear enough.
Anyway guys, I see how it is here. I wont bother this forum again. Feel free to delete this thread if you want to avoid any “academic” confusion.
frob said: In either event, it seems that you're focusing far too much on the academic study and what a book says or a website says.
And this is one reason among others why some of us prefer that “patterns” not be a part of the conversation at all, or only as a taxonomic tool. It becomes too natural to focus on the patterns rather than the actual code that embodies them. As the GOF book itself says (or I seem to recall), patterns are just labels for things devs do that we use to make communication among ourselves easier. But I still recall sitting in a software engineering course at university, overhearing my classmates trying to figure out what pattern the prof wanted them to use to solve the example problem we were given. Exactly backwards of what I would recommend!
I would not focus over much on patterns in your actual dev work, but it is helpful to know what the words mean so you can understand what other programmers are saying about their code. Give your code these labels after you have written it, don't write your code to a pattern.
I've never seen a forum so specific about how to interpret answers as stated in the link you posted. You must be getting a lot of people pissed if you had to go in such detail on how not to be rude, or “reacting like a loser”. Nice one… that's not rude at all.
The fact is that I asked a question. Then I clarified if I mispoken when it came to the Director by saying that it is not a pattern, but a participant. And I mentioned that this participant guaranty the D.I.P. And still, the moderator reply was “Director” on it, Oberon is correct that it's not a design pattern in the book.”…
Patterns are not just label as it was said, they are tools that identify and solve problems, and help devs communicate. And they are deeply linked with the solid principles, which I guess it is more academic non-sense in this forum, which is why probably the Director class (hopefully at this point for the third time you understood it is not a pattern what I am talkin about) is important.
But since I have nothing to provide to this forum, I'll just go somewhere else.
Cheers mates, have a good one.
ps: Please feel free to delete my user, and this thread because I don't know how to do it.
rudiHammad said: And they are deeply linked with the solid principles, which I guess it is more academic non-sense in this forum, which is why probably the Director class (hopefully at this point for the third time you understood it is not a pattern what I am talkin about) is important.
For the third time, “director” is not a part of builder. It is a part of that specific example of builder that extends it - it's just the specific thing in the example that is calling the builder. You can have “builders” without anything that resembles the “director” in the example. I frequently use the builder pattern from free functions, for example - no classes involved at all, apart from the builder itself and the thing that the builder builds. You can find some discussion of “directors” here: https://refactoring.guru/design-patterns/builder
You can go further and extract a series of calls to the builder steps you use to construct a product into a separate class called director. The director class defines the order in which to execute the building steps, while the builder provides the implementation for those steps.
Having a director class in your program isn’t strictly necessary. You can always call the building steps in a specific order directly from the client code. However, the director class might be a good place to put various construction routines so you can reuse them across your program.
In addition, the director class completely hides the details of product construction from the client code. The client only needs to associate a builder with a director, launch the construction with the director, and get the result from the builder.
So it appears, upon further digging, that this IS a pattern or idiom of its own - it just isn't a GOF pattern, and it isn't universally applied with builder.
Almost nothing should be treated as hard rules to follow in software engineering and you should be skeptical of anyone who tries to tell you that you should always follow a given principle. This includes your profs, whose knowledge of software engineering will frequently be at least five years out of date. Sometimes even more so. ?
@Oberon_Command ahahaha, now I see where you are coming from. Who need solid!? I see now why you dont understand why the director IS part of the pattern.
Jesus…I keep replying! I cant help my self. ps: there are also youtube videos that prove earth is flat. Just saying…something to think about.
rudiHammad said: And they are deeply linked with the solid principles,
Because I missed it the first time I read the post - no, patterns have little to do with SOLID. A “pattern” is just a name for a structure that frequently emerges in code naturally. There are design patterns that show up a lot in code that doesn't follow SOLID or any of the other design advice acronyms like GRASP or CUPID. “Builder” wasn't invented to satisfy SOLID principles, it was a thing that devs in the ‘90s kept doing and the GOF authors happened to notice and give the pattern they saw a name. If someone has taught you otherwise, then I’m afraid you may need to find another source or take your current one with a grain of salt.
I encourage you to read the links I've given you and watch the talk with an open mind. That will take you more than an hour, but even if they don't change your mind, the competing perspectives will help you understand better why you believe what you believe.
I mean…wow… I am speachless… that explains a lot. I encourage you keep this kind of thought away from new programmers because they might believe you. I encourage you to read books(unfortunately that takes more than an hour) instead of looking for videos that prove your point. You can start by Design patterns head first, where it explain how every single solid principle is reflected in each pattern when applicable. In fact, at the end of each lesson, they summarize which solid principle you encouter in the pattern. And also they explain how somethimes, the o.c.p cannot be applyied for instance and why. 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. I just hope new programmers dont actually believe some of the things you say, for their own good.
Jesus, this day was a complete waste. But entertaining.
