4 ms·

I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usua

by GuB-42 4y ago

I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usually in Java. 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. Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.

CharlieDigital 4y ago
The point of using it by the book is that we can talk about it with a common nomenclature.
- P5fRxh5kUvp2th 4y ago
  That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
  - bluGill 4y ago
    The point of documenting what is in common use so we can talk about it. If we don't talk about it then we don't need documentation.
arinlen 4y ago
> 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.

by GuB-42 4y ago

CharlieDigital 4y ago

The point of using it by the book is that we can talk about it with a common nomenclature.

P5fRxh5kUvp2th 4y ago
That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
- bluGill 4y ago
  The point of documenting what is in common use so we can talk about it. If we don't talk about it then we don't need documentation.

arinlen 4y ago

> 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.