41–50 of 126 posts
Part of the problem with OO is the other stuff we heaped on it, while still calling it OO. So, we're not always assessing "pure" OO when we talk about it. For instance, immutability and OO are diametrically opposed concepts. Objects were supposed to encapsulate data (state) and expose operations that would mutate that state in a controlled fashion. But, we then imposed this immutability requirement, whereby we create…
Earlier quoted context omitted.
I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it…
> Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. That's because there are no decent OO based web UIs, because the web development experience and stack is a total mess to begin with.
You can see the disastrous implications of this feature with the ID mangling needed for Asp.net webforms, and the utterly miserable workflow that creates.
Oh?
To some point I can follow the argumentation of the author. However, I do not see any superior alternative to the OO paradigm especially combined with Unit testing. Thus, HN, what are the alternatives to OO ?
Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with u…
As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?
C structs were used obviously to hold data. Structs were created after analyzing the data to be stored, determining multiplicities, lifetime, etc.
C functions were frequently large and handled numerous concerns. Programmers usually started with one function and split off other functions as needed mostly to take advantage of commonality and to avoid deep nesting.
As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?
This is the basic stategy that I try to follow as much as possible: Classes that hold data have no methods (beyond getters/setters). Classes that implement behavior have no mutable state; they exist as namespaces for the functionality that they provide. I've been quite successful with this approach. It leads to code that is easier to understand than a big ball of stateful objects.
The only caveat to this approach is that for some cases you will need a state accumulator of some sort. But those state manipulations are isolated and easy to deal with.
As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?
This is the basic stategy that I try to follow as much as possible: Classes that hold data have no methods (beyond getters/setters). Classes that implement behavior have no mutable state; they exist as namespaces for the functionality that they provide. I've been quite successful with this approach. It leads to code that is easier to understand than a big ball of stateful objects.