Timeline for The motivation behind the Factory Method design pattern
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 3, 2022 at 19:47 | answer | added | gnasher729 | timeline score: 0 | |
| Apr 3, 2022 at 19:00 | comment | added | Doc Brown | @YoavKlein: several of the GoF patterns are most useful when creating libraries or frameworks which should be reused or extended by a client who cannot change the libraries' code. | |
| Apr 3, 2022 at 16:39 | comment | added | DaveG | Just buy the Gang of Four Design Patterns book. That not only has good explanations and motivations for each pattern, it also has a sample application that shows the real world use of each pattern. It's well worth the money. | |
| Apr 3, 2022 at 12:51 | vote | accept | YoavKlein | ||
| Apr 3, 2022 at 12:48 | answer | added | Christophe | timeline score: 3 | |
| Apr 3, 2022 at 12:03 | comment | added | Filip Milovanović | P.S. Also, as I mentioned in the linked answer, today most languages support lambdas, which can play the role that the virtual factory method in the base class has in the traditional pattern - if all you need is a single factory method. So, you have a simplified version of this pattern any time you inject a lambda that creates some other object, but returns it as some interface or base type, and than call that lambda somewhere in the logic within the containing class, | |
| Apr 3, 2022 at 11:56 | comment | added | Filip Milovanović | Or, perhaps you want your application to support multiple platforms, and you have some piece of platform-independent logic (defined in the base classes) that involves creating a platform-specific resource, that, once created, can be used in a platform-independent way - so you provide an implementation for each platform. These are different scenarios that have a need for a similar kind of separation of concerns. But yeah, if you don't need that, then there's no need to apply it - the pattern is not something you default to, but something you deliberately use to allow for that separation. 2/2 | |
| Apr 3, 2022 at 11:56 | comment | added | Filip Milovanović | Well, the key idea is that you have a piece of business logic that at some point needs to create a certain abstract type (and operate on it), but also needs to stay independent of the concrete type - it leaves that decision to something else. Frameworks of the kind I mentioned provide a good example of how this need might arise, but as Christophe said, you can have a similarly reusable component even within a standalone application, resulting from separation of concerns, providing a DRY way to have similar variants, or letting you support future requirements by extending existing code. 1/2 | |
| Apr 3, 2022 at 9:34 | comment | added | Christophe | @YoavKlein the pattern is potentially useful, even in a standalone application, as soon as you use interfaces or subclassing and have loose coupling between your app components. There are people using this pattern without even knowing it’s a pattern. | |
| Apr 3, 2022 at 8:36 | comment | added | YoavKlein | @FilipMilovanović, so you're saying that, say when I build a standalone application (not a library or framework that I want to enable clients to extend) - and I know the kinds of products I want to use - there is no point using this pattern? It seems weird that so many people got it wrong.. | |
| Apr 3, 2022 at 8:26 | comment | added | Filip Milovanović | The primary source, the GoF book, actually opens with a "Motivation" section where they explain this. If you haven't come across this framing of the problem, it's because all of the online information represents secondary sources, and many authors either fail to express this clearly, or don't really understand the pattern itself. The maze example is actually from later on in the book, they use it to illustrate how to implement the pattern, but they don't lead with it. | |
| Apr 3, 2022 at 8:10 | comment | added | YoavKlein | @FilipMilovanović, why isn't this assumption presented anywhere? Seems like it is a fundemental requirement... | |
| Apr 3, 2022 at 7:16 | comment | added | Filip Milovanović | The assumption is something like: you're writing a customizable library that other people can extend, and you have points in your logic where you need to instantiate objects of an unknown type (to be chosen, or even created, by the users of your library). The Factory method hierarchy can be separate from your core logic, but doesn't have to be. See my answer here for more details. | |
| Apr 3, 2022 at 7:02 | comment | added | Hartmut Braun | Your very last paragraph describes a problem I have with a lot of patterns. | |
| Apr 3, 2022 at 5:30 | history | asked | YoavKlein | CC BY-SA 4.0 |