5 ms·

>solutions to imaginary problems This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though. A design pattern is sometin

by wackro 5y ago

>solutions to imaginary problems This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though. A design pattern is someting that will naturally crop up if you adhere to certain design principles. If you follow a principle of separating instantiation logic from other logic then you will start to see factories. If you combine multiple complex parts of your code into simpler ones then you will see facades. GOF is a reference book for some patterns that have been observed as being common, with examples that are essentially academic. It is not a how-to guide for OOP.

rolisz 5y ago
But many programmers use it as a how-to guide. I've had people tell me "but that's how it's done in GOF", even if the design pattern was a poor fit for the problem at hand, just because there was some superficial resemblance to one of the examples in the book.
- dopidopHN 5y ago
  I remember trying really hard to find case where I could use a pattern in my code as a junior dev.
- ghosty141 5y ago
  but this is not the fault of the book but of bad teaching.
- jcelerier 5y ago
  Ask them to re read chap.1 or 2 where it says black-on-white that this is not a set of mandatory rules. (Same for Clean Code by the way which is often taken as gospel against the wishes of its own author!)
agumonkey 5y ago
But even factories and all these terms are very vacuous and only present because objects are giving bad solutions.
- wackro 5y ago
  I put it to you that the OOP concept of a factory exists because in OOP your factory is often (though not always) a type, and types tend to need names. In e.g. FP there are no objects and therefore no instantiation but you can separate this kind of logic all the same, except you wouldn't call it anything, or would name it like any other function. For the record I've been doing mainly OOP and have dabbled in F# so I'm happy to learn something today.
  - agumonkey 5y ago
    That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.
    - native_samples 5y ago
      No - that's not what factories are at all. If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language). Factories exist for a few different reasons: 1. When there are more things to configure about the newly created objects than makes sense to pass as function properties. 2. When an API designer wishes to provide backwards compatibility to his clients, which adding function parameters doesn't do. 3. When there's a need to separate how something is constructed from where it is constructed, i.e. you create a "factory" or "builder", configure what you want it to do, but then don't directly use it. Instead you pass it off to some other code that uses it when it needs to. These are fundamental concepts. They aren't some side effect of how OO languages work. I think the disdain for them comes largely from programmers who haven't actually done many different types of programming. If all you've ever done is write web apps then yeah they're sometimes going to seem a bit useless. If you've shipped a type safe library API that you've needed to maintain compatibility for over a period of many years, maybe that will be used in ways you didn't anticipate so you can't just arbitrary refactor yourself out of a hole, suddenly these sorts of abstractions start to look pretty good.
zamalek 5y ago
That exact sentiment exists deep in my comment history here: I think I used the word "blueprint" if you care enough to fact check that. That is why I said I don't hold issue with the content of the book. My issue is that the book is useful. It helps solve the artificial complexity introduced by OOP.
- wackro 5y ago
  I see. It was the ambiguity over your usage of 'imaginary problems'. But yes - your previous comments seem to suggest we're actually on the same page regarding patterns.
- psd1 5y ago
  Agreed that it's never good to have new social problems created by whatever you did to solve the previous problem. But that's the nature of doing stuff. I own a car. Great, now I have maintenance concerns. But it's still a net positive, which is why we do it. If oop creates more work than the value of brings, then we should scrap it. But I've seen some pretty bad procedural code, so I don't think that's a given.

by wackro 5y ago

rolisz 5y ago

But many programmers use it as a how-to guide. I've had people tell me "but that's how it's done in GOF", even if the design pattern was a poor fit for the problem at hand, just because there was some superficial resemblance to one of the examples in the book.

dopidopHN 5y ago
I remember trying really hard to find case where I could use a pattern in my code as a junior dev.
ghosty141 5y ago
but this is not the fault of the book but of bad teaching.
jcelerier 5y ago
Ask them to re read chap.1 or 2 where it says black-on-white that this is not a set of mandatory rules. (Same for Clean Code by the way which is often taken as gospel against the wishes of its own author!)

agumonkey 5y ago

But even factories and all these terms are very vacuous and only present because objects are giving bad solutions.

wackro 5y ago
I put it to you that the OOP concept of a factory exists because in OOP your factory is often (though not always) a type, and types tend to need names. In e.g. FP there are no objects and therefore no instantiation but you can separate this kind of logic all the same, except you wouldn't call it anything, or would name it like any other function. For the record I've been doing mainly OOP and have dabbled in F# so I'm happy to learn something today.
- agumonkey 5y ago
  That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.
  - native_samples 5y ago
    No - that's not what factories are at all. If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language). Factories exist for a few different reasons: 1. When there are more things to configure about the newly created objects than makes sense to pass as function properties. 2. When an API designer wishes to provide backwards compatibility to his clients, which adding function parameters doesn't do. 3. When there's a need to separate how something is constructed from where it is constructed, i.e. you create a "factory" or "builder", configure what you want it to do, but then don't directly use it. Instead you pass it off to some other code that uses it when it needs to. These are fundamental concepts. They aren't some side effect of how OO languages work. I think the disdain for them comes largely from programmers who haven't actually done many different types of programming. If all you've ever done is write web apps then yeah they're sometimes going to seem a bit useless. If you've shipped a type safe library API that you've needed to maintain compatibility for over a period of many years, maybe that will be used in ways you didn't anticipate so you can't just arbitrary refactor yourself out of a hole, suddenly these sorts of abstractions start to look pretty good.

zamalek 5y ago

That exact sentiment exists deep in my comment history here: I think I used the word "blueprint" if you care enough to fact check that. That is why I said I don't hold issue with the content of the book. My issue is that the book is useful. It helps solve the artificial complexity introduced by OOP.

wackro 5y ago
I see. It was the ambiguity over your usage of 'imaginary problems'. But yes - your previous comments seem to suggest we're actually on the same page regarding patterns.
psd1 5y ago
Agreed that it's never good to have new social problems created by whatever you did to solve the previous problem. But that's the nature of doing stuff. I own a car. Great, now I have maintenance concerns. But it's still a net positive, which is why we do it. If oop creates more work than the value of brings, then we should scrap it. But I've seen some pretty bad procedural code, so I don't think that's a given.