OOP has served me well. It is a powerful concept. Problem is that people can misuse and abuse things.
The Case Against OOP Is Wildly Overstated
111–120 of 312 posts
Re: The Case Against OOP Is Wildly Overstated
#112Earlier quoted context omitted.
The term we like to use is "the pit of success". It shouldn't be hard to do it the right way.
"The pit of success" is a great guiding principle when it comes to the design of codebases. Forget about "design patterns" and just focus on _how do I allow developers to focus on creating things that are adding value, rather than faffing around with extraneous things_. I can't tell you how many times I've seen a project go full onion-pattern with a web service that basically just recieves HTTP requests and makes a f…
The onion anti-pattern is Separation of Concerns taken as mythology, not practicality.
A reasonable way to OOP is: 1. Understand your domain and work hard to match its structures. 2. Delegate and separate where there's an unquestionable benefit, not for the sake of it. 3. Likewise for inheritance hierarchies. 4. Don't create entities unnecessarily.
Every single decision should have a clear practical rationale. SOLID on its own is not a rationale - it's a guide, but to use it you need to understand what a concern is from the domain POV, not from the code POV.
Re: The Case Against OOP Is Wildly Overstated
#113The problem I've always had with these back-and-forths between various programming philosophies is that the very nature of the argument exposes the reason the arguments don't work. The most common (but not only) way each side argues its point is to take some contrived example and show how philosophy X does it well, and how philosophy Y does it terribly. These examples are often ranted about by the "Y" proponents beca…
So let's say I've decided to sit down and write a digital audio workstation. I've got to pick at least one programming language and at least one general programming style. Let's say I pick C++ and (somewhat by implication) a generally OOP style.
Someone comes along and says "oh, you could do this much better with Haskell and functional programming".
How can you argue that the comparison involves an "X and Y" that are not designed to solve the same problem? Advocates for languages and programming styles are generally doing so on the basis that there is a broad class of software development problems/projects that will benefit from the use of their preferred "X and Y".
Sure, there are some DSLs that are clearly not intended to be compared with (say) C++. And there are some overall programming styles that clearly suite certain kinds of software much more than others (e.g. the absence of an event loop somewhat changes everything, as does high level distributed parallelism).
But OOP isn't an example of such a thing.
Re: The Case Against OOP Is Wildly Overstated
#114This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.
Agreed. The biggest problem with OOPS lies in its original premise: that code and data should be the same thing! This is grevious error, IMHO, that leads to nothing but problems: endless boilerplate code, lots of "interfaces" that essentially do nothing (that couldn't be done directly with said data), and debugging nightmares. I much prefer to work with systems where code and data are separate and never the twain sha…
I think both conceptions are important. On one hand, some code is naturally related to certain data and hence we should accordingly design the program. On the other hand, complex and distributed programs have code which must be dynamically bound to different data. OOP focuses on only one aspect but does it very well. How to adequately support the opposite aspect is not clear. At least there are many ways how this can be done.
Re: The Case Against OOP Is Wildly Overstated
#115Earlier quoted context omitted.
So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ? I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.
You might want to consider examining another programming language for clues here. Perhaps look to a language that has a more modern approach to state such as Clojure.
My understanding is that Clojure is basically lisp implemented inside the Java ecosystem. I'm not sure how that makes it "modern" given that the only higher level language older than lisp is the original version of Fortran.
Re: The Case Against OOP Is Wildly Overstated
#116Earlier quoted context omitted.
Essentially, yes, but in a way that sounds more careful than what you saw in that Fortran program. If it absolutely has to be stateful, like with a db connection for example, then there's no getting around that, but what you can do is (1) not bury it in a bunch of stateful objects that didn't have to be stateful, which can cause cascading errors when either one of them misbehaves and also makes it difficult to isolat…
More concretely, for every bit of state in the program I'm interested in two big questions, each with two subquestions: 1.) Who can access this state, and which of those accesses allow writes vs. which are read-only? 2.) What is the lifetime of that state, and what portion of that lifetime is mutable vs. read-only? Java-style OOP can control #1, but makes no distinction between reads & writes. C++ const correctness a…
That would be really cool, but I think enforcing that is undecidable. My gut tells me that having that language feature at compile time is the same as the Halting Problem.
Re: The Case Against OOP Is Wildly Overstated
#117So you fix OOP by taking away the things that make OOP, OOP? That just sounds like procedural programming with extra steps. Also, as an aside, I wouldn't call DRY a 'rock solid foundation' of programming. People do some weird contortions to make code DRY that end up causing my harm then good. Separations of Concerns is far more important. DRY is fine when applied within the scope of a feature, but not cross features.…
I knew a programmer who was all in on DRY and it was the heart of many stupid debates. Not only did result in a crazy inheritance and dependency tree, there were tons of many useless functions. Like having "logger.log(obj.read_stream())" in a few places would be "WET" the API got cluttered clutter with crap like obj.read_and_log_stream()
Re: The Case Against OOP Is Wildly Overstated
#118People love to hate on inheritance and suggest that there are no cases where its use is warranted. But inheritance absolutely is used, and successfully, in many frameworks. For example GUI frameworks [1] [2] or server-side web frameworks [3]. People have been writing code in frameworks like this for ages and as far as I can see they worked well. Including key use cases such as being able to use the provided component…
Just because there's examples of successful usages doesn't necessarily mean that it's "good" or even a model for how we do things moving forward. Picking that specific example [NS|UI]Button, they're dreadful to work with. Honestly. Customizing them is difficult to impossible. It's often easier to just compose them into a different container because the extension points couldn't possibly be designed in a way that gives you all the flexibility you need.
Yes, it works, and yes, there are great systems built with OOP patterns. The same can be said of C++. That doesn't mean they're good, or we should choose it as our tool moving forward.
Re: The Case Against OOP Is Wildly Overstated
#119There's this "bastard OOP" where "ellipse isa circle" going around which completely doesn't work in practice. But there's "true OOP" that follows SOLID principles (particularly LSP) that actually makes a lot of sense.
Unfortunately, this "bastard OOP" is the more popular variant, with many "bastard OOP" examples from the late 90s and early 00s running around textbooks, polluting the minds of student programmers at the time. This article does a good job poking fun at it, with "class Dog extends Animal", which is complete nonsense.
Actually learning SOLID principles, as well as the historical 80s style of OOP, goes a long way towards fixing problems.
Re: The Case Against OOP Is Wildly Overstated
#120Earlier quoted context omitted.
So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ? I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.
Essentially, yes, but in a way that sounds more careful than what you saw in that Fortran program. If it absolutely has to be stateful, like with a db connection for example, then there's no getting around that, but what you can do is (1) not bury it in a bunch of stateful objects that didn't have to be stateful, which can cause cascading errors when either one of them misbehaves and also makes it difficult to isolat…
(2) sounds very similar to the way I have typically handled db access in C++. However the kind of state I was referring to is more about the internal computational data used by the program than about external resources.