4 ms·

> For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory

> For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place. This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain. Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?

GuB-42 4y ago
You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides. Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete". Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name. The issue I have with what I called "design pattern fetishism" is that: - Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers. - Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex). - Side note: singletons are global variables and shall be treated as such.

GuB-42 4y ago

You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides. Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete". Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name. The issue I have with what I called "design pattern fetishism" is that: - Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers. - Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex). - Side note: singletons are global variables and shall be treated as such.