51–60 of 126 posts
As somebody who works on many different OOP-projects, could somebody tell me how I should structure my software if not using OOP?
o.f(a,b,c)
f(o,a,b,c)
OOP is not a failure. But overengineering is another thing. (Sometimes I heard "Never write static function/method! Do it in OOP way!", though it doesn't make the code simpler or cleaner)
The point of OOP isn't to predict the future. You should be actively aware that you cannot know the future and leave youself room for change.
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…
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…
Well, that's what the OP in OOP means. It means you are oriented towards objects, and away from everything else.
What's the difference between writing a test and doing TDD? In TDD the tests are the center of your universe.
Plus there's the fact that "Everything is an Object" was a very common slogan for OOP.
Of course you can write non-objects in your object oriented code... An object is made of non-objects! But OOP means when you are asking architecture questions you sort out your names and your methods first, and functions fill in the gaps.
Compare to (old school) JavaScript where everything is a function to start, and you add prototypes and methods only when you really need them. (RIP JavaScript, long live OOP/ES6)
Now that computer hardware manufacturers are moving toward providing more CPU cores that allow for higher degrees of parallelization within single applications - development strategies that make it easier to keep parallel processes from working against each other are becoming more preferable.
Looking at OOP's success as binary is inappropriate. OOP was the right tool for the time and hardware that was available. It served its purpose, but unless its shortcomings on modern and near-future hardware can be addressed... it will fall out of vogue and be regarded as the wrong choice to make.
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…
OOP is also a tool that others have used to build things that many of us use all the time (I'm looking at you DOM API and CSS) so it's difficult to truly escape from OOP. You may never like it, but learning it will deepen your understanding of many other tools.
P.S. Link to the original interview: http://www.stlport.org/resources/StepanovUSA.html
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…
> 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."? Because there are many low skill, poorly-informed people who write code still believe these things. In particular that "OOP" is automatically equivalent to "better quality code." It’s a sort of cargo cultism th…
Quality in practical outcomes for building projects, that is, not code asthetics.
The problem is that 'functional code' means 'spagetti code' for many 'low skill' people, and 'write once maintain never' perl style code for many other 'smart' people.
Both are rubbish, terrible low quality useless code outcomes.
OOP doesn't fix everything, but its a great lowest common demoninator for code that does the job. Its not exciting. It has stateful bugs. ...but anyone can do it and it gets the job done at scale; orders of magnitude better than any other coding paradigm I'm aware of.
You want a hard problem to solve?
Go figure out a way to make functional programming scale the same way, you'll start a revolution.
...but in my experience, its the frustrated 'smart' folk who want to write their maintain-never code who push FP as a replacement for OOP.
For computers built in the late 80's and subsequent couple of decades, OOP was a fine abstraction that furthered software development in many ways. When you had one thread running your whole program, it was okay to have mutable data all over the place with complex interactions between parts of your program. Developers could keep it all straight in their heads, so OOP added some structure that was very helpful. Now th…