6 ms·

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything rel

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything related to the content of the book. It's that the book exists at all: it's a book filled with solutions to imaginary problems. When using a procedural language the first thing you do is start implementing a solution. When using OOP, you first have to solve the imaginary problems created by OOP, only then can you start down the path of typing out a solution. It's significantly more difficult to refactor OOP (even with great tools) than it is procedural. If you could spend 20% less brain power, possibly 40% fewer keystrokes to describe the exact same solution, why wouldn't you?

_pmf_ 5y ago
> it's a book filled with solutions to imaginary problems. Have you even read it? I'd say it has more deep real world examples than almost any other SW engineering book I've read.
- fulafel 5y ago
  IME it happens often that these categories overlap, when software gets entangled in incidental compexity.
ecshafer 5y ago
Design patterns as a concept exist without OOP. Even in procedural code or functional code you have concepts like a strategy pattern, or how do I get version X vs Y of object A. These things arise in any code you are writing a sufficient complexity.
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
jcelerier 5y ago
I'm sorry but this is absolutely ridiculous. I sometimes teach programming to uni students, we make toy software like paint programs with a GUI in Java, networked game in C, that kind of thing. I always have a good proportion of the class coming up with many patterns entirely on their own without any prior exposure, and I love their looks when I show them that the nebulous concept they came up with actually has a name and is well defined (and the best solution to the problems they encounter given the tools they have).
- activitypea 5y ago
  If a good proportion of an undergrad class is intuitively coming up with solutions that have some commonality, is that commonality really valuable? Observing it is neat, I just take issue with people treating design patterns as a northstar for quality software development
sunny3 5y ago
My experience with the book and its patterns has been that there's an issue and some developers recognize that it could be best resolved with x, y, or z pattern. Then the developers go to extreme length to make sure the implementation adhere to the the 'principles' or 'spirits' of those patterns, so much so that it creates unnecessary complexity (e.g., unneeded layers of abstraction) and friction in other components (to accommodate the 'purity' of that implementation). What's worse, it's very difficult to challenge such implementation in code reviews, since it's originated by GOF, which automatically makes it legitimate. The worst part, though, is that you have to maintain the implementation, any deviation from those patterns is seen as corner-cutting.

_pmf_ 5y ago

> it's a book filled with solutions to imaginary problems. Have you even read it? I'd say it has more deep real world examples than almost any other SW engineering book I've read.

fulafel 5y ago
IME it happens often that these categories overlap, when software gets entangled in incidental compexity.

ecshafer 5y ago

Design patterns as a concept exist without OOP. Even in procedural code or functional code you have concepts like a strategy pattern, or how do I get version X vs Y of object A. These things arise in any code you are writing a sufficient complexity.

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

jcelerier 5y ago

I'm sorry but this is absolutely ridiculous. I sometimes teach programming to uni students, we make toy software like paint programs with a GUI in Java, networked game in C, that kind of thing. I always have a good proportion of the class coming up with many patterns entirely on their own without any prior exposure, and I love their looks when I show them that the nebulous concept they came up with actually has a name and is well defined (and the best solution to the problems they encounter given the tools they have).

activitypea 5y ago
If a good proportion of an undergrad class is intuitively coming up with solutions that have some commonality, is that commonality really valuable? Observing it is neat, I just take issue with people treating design patterns as a northstar for quality software development

sunny3 5y ago

My experience with the book and its patterns has been that there's an issue and some developers recognize that it could be best resolved with x, y, or z pattern. Then the developers go to extreme length to make sure the implementation adhere to the the 'principles' or 'spirits' of those patterns, so much so that it creates unnecessary complexity (e.g., unneeded layers of abstraction) and friction in other components (to accommodate the 'purity' of that implementation). What's worse, it's very difficult to challenge such implementation in code reviews, since it's originated by GOF, which automatically makes it legitimate. The worst part, though, is that you have to maintain the implementation, any deviation from those patterns is seen as corner-cutting.