3 ms·

> I think that this is also part of the reason why there has been a shift away from design patterns (...) There is no such shift. Design patterns are ubiquitou

> I think that this is also part of the reason why there has been a shift away from design patterns (...) There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern. A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.

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.
CharlieDigital 4y ago
I work at a startup with former Amazon engineers in the mid 20's and early 30's. Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns. Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
- bluGill 4y ago
  Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
  - arinlen 4y ago
    > Design patterns make the most sense after a few requirement changes. No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not. > Startups don't have that yet and think getting to market is more important than staying in the market for long. This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
    - bluGill 4y ago
      > Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for. It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.

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.

CharlieDigital 4y ago

I work at a startup with former Amazon engineers in the mid 20's and early 30's. Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns. Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.

bluGill 4y ago
Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
- arinlen 4y ago
  > Design patterns make the most sense after a few requirement changes. No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not. > Startups don't have that yet and think getting to market is more important than staying in the market for long. This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
  - bluGill 4y ago
    > Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for. It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.