4 ms·

> OO actually works well for scaling complexity, much better than toy immutable functions do. Sure, but the problem is that OO is frequently applied where you

> OO actually works well for scaling complexity, much better than toy immutable functions do. Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled. A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making the point any further: http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_use_with_the_Abstract_Factory_pattern http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us... It is my fervent hope and wish that all programmers someday accept that there is no universal methodology, that FP and imperative and OO all have their place and their faults, and that it is OK to sometimes not use one of them somewhere.

seanmcdirmid 12y ago
If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible). And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).
- robmccoll 12y ago
  > If you get good at programming... This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.
  - Chris_Newton 12y ago
    I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools. This is one of the biggest problems with Java — and other “pure OO”, “everything is an object” languages of the same style — particularly from a teaching perspective: when all you have is a class, every problem looks like an object. If we present a language like Java as being the default, standard, safe option, how are new developers ever going to gain enough knowledge and experience to realise that their elaborate design with seven different classes in Java could have been replaced by a single 10-line function in Python, or a few short lines of Prolog, or a single query in SQL?
unclebucknasty 12y ago
>the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled. You nailed it. And, so did the author, with this: >so often I find I’m reading code that looks more like a plan for something that solves a problem, rather than something that actually solves a problem. Java--or perhaps the OO culture that came up with it, or perhaps the enterprise culture in general, or perhaps all three--does encourage a certain overengineering mindset. I am speaking as a recovered victim. This permeates the entire culture. Remember when the Design Patterns books were first popular? Every Java dev was looking for a way to wedge in as many patterns as possible. There was a real sense that it was required to do development right. I think this (along with reading Java's APIs) is where Java devs began to fancy ourselves Architects Of Everything. You couldn't just solve a problem, no matter how simple. Instead, you had to develop something that could be infinitely extended or modified in the future. And, you'd better be sure that nary a public interface required updating if those future changes were necessary. Nevermind that you layered on extra classes, instantiated everything with a factory, and increased the initial complexity of using the code by orders of magnitude. So, you were no longer solving a problem. Instead, you were architecting a flexible solution that could support solving the problem, along with every future variation of the problem you could conceive at the time. Then, you implemented your solution for the actual problem within this new, broader mini-framework you just created. So, when reading this code, it's not uncommon to go through layer after layer trying to figure out where the actual work was being done. But, the problem is that those future changes seldom came. So we were guaranteeing that our initial solution was overly complex and creating all of this baggage, while relatively infrequently redeeming that heavy cost in terms of avoidance of actual future pain that we imagined.
cust_support 12y ago
I totally agree if scalability also implies flexibility. I've seen too many cases where a developer will over-engineer something for flexibility when it is never, ever going to be necessary. For example, you will never, ever break a facade into a composite. I've seen a facade that is a wrapper for some external system engineered into a composite of Aggregators, Generators, Executors, etc. but the developer willfully ignored the fact that each of these pieces still have a dependency on the external systems/structures and are never likely to have separate implementations. At the same time, I've seen OO used in the enterprise as a poor governance mechanism. For example, I've seen AAA unit test "frameworks" that included abstract methods solely to force developers to follow the pattern. But I just jumped right out of that shit by ignoring the instruction to "extend from AAAContextBase".

seanmcdirmid 12y ago

If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible). And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).

robmccoll 12y ago
> If you get good at programming... This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.
- Chris_Newton 12y ago
  I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools. This is one of the biggest problems with Java — and other “pure OO”, “everything is an object” languages of the same style — particularly from a teaching perspective: when all you have is a class, every problem looks like an object. If we present a language like Java as being the default, standard, safe option, how are new developers ever going to gain enough knowledge and experience to realise that their elaborate design with seven different classes in Java could have been replaced by a single 10-line function in Python, or a few short lines of Prolog, or a single query in SQL?

unclebucknasty 12y ago

>the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled. You nailed it. And, so did the author, with this: >so often I find I’m reading code that looks more like a plan for something that solves a problem, rather than something that actually solves a problem. Java--or perhaps the OO culture that came up with it, or perhaps the enterprise culture in general, or perhaps all three--does encourage a certain overengineering mindset. I am speaking as a recovered victim. This permeates the entire culture. Remember when the Design Patterns books were first popular? Every Java dev was looking for a way to wedge in as many patterns as possible. There was a real sense that it was required to do development right. I think this (along with reading Java's APIs) is where Java devs began to fancy ourselves Architects Of Everything. You couldn't just solve a problem, no matter how simple. Instead, you had to develop something that could be infinitely extended or modified in the future. And, you'd better be sure that nary a public interface required updating if those future changes were necessary. Nevermind that you layered on extra classes, instantiated everything with a factory, and increased the initial complexity of using the code by orders of magnitude. So, you were no longer solving a problem. Instead, you were architecting a flexible solution that could support solving the problem, along with every future variation of the problem you could conceive at the time. Then, you implemented your solution for the actual problem within this new, broader mini-framework you just created. So, when reading this code, it's not uncommon to go through layer after layer trying to figure out where the actual work was being done. But, the problem is that those future changes seldom came. So we were guaranteeing that our initial solution was overly complex and creating all of this baggage, while relatively infrequently redeeming that heavy cost in terms of avoidance of actual future pain that we imagined.

cust_support 12y ago

I totally agree if scalability also implies flexibility. I've seen too many cases where a developer will over-engineer something for flexibility when it is never, ever going to be necessary. For example, you will never, ever break a facade into a composite. I've seen a facade that is a wrapper for some external system engineered into a composite of Aggregators, Generators, Executors, etc. but the developer willfully ignored the fact that each of these pieces still have a dependency on the external systems/structures and are never likely to have separate implementations. At the same time, I've seen OO used in the enterprise as a poor governance mechanism. For example, I've seen AAA unit test "frameworks" that included abstract methods solely to force developers to follow the pattern. But I just jumped right out of that shit by ignoring the instruction to "extend from AAAContextBase".