Goodbye, Object Oriented Programming • Hacker News Board

Re: Goodbye, Object Oriented Programming

#21

Post by millstone » Sun, Jul 24, 2016, 8:03 PM UTC

Let me try to list the objections:

1. Inheritance creates dependencies on their parent class

2. Multiple inheritance is hard

3. Inheritance makes you vulnerable to changes in self-use

4. Hierarchies are awkward for expressing certain relationships

All true. But likewise, functions introduce dependencies on their arguments, and data structures introduces dependencies on their fields. You must consider your dependencies carefully when designing any software interface.

The task of software architecture is not to go around categorizing everything into a taxonomies. Inheritance is just one tool in your software interface toolbox.

5. Reference semantics may result in unexpected sharing

This has more to do with reference semantics than objects.

6. Interfaces achieve polymorphism without inheritance.

Interfaces long for inheritance-like features. For example, see Java 8's introduction of default methods, or the boilerplate involved in implemetning certain Haskell typeclasses.

Re: Goodbye, Object Oriented Programming

#22

Post by nitsujin » Sun, Jul 24, 2016, 8:03 PM UTC

Artlav wrote: post #17

I wonder if someone invented the "modular" programming yet. Judging by the UNIX paradigm of the command line tools, the idea is clearly out there. Instead of objects, do modules - things that do one thing, and carry minimal dependencies. You need a banana? Grab the banana module. You need a banana with ice-cream center? Feed the "center" callback of the banana module with "ice-cream" instead of "banana intestines". Y…

That's functional programming.

Re: Goodbye, Object Oriented Programming

#23

Post by Illniyar » Sun, Jul 24, 2016, 8:03 PM UTC

DanWaterworth wrote: post #6

Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. Like react?

Is this same react where your components keep internal state (called state) and every component must be created by extending a base class?

Re: Goodbye, Object Oriented Programming

#24

Post by hetfeld » Sun, Jul 24, 2016, 8:04 PM UTC

Artlav wrote: post #17

I wonder if someone invented the "modular" programming yet. Judging by the UNIX paradigm of the command line tools, the idea is clearly out there. Instead of objects, do modules - things that do one thing, and carry minimal dependencies. You need a banana? Grab the banana module. You need a banana with ice-cream center? Feed the "center" callback of the banana module with "ice-cream" instead of "banana intestines". Y…

Yeah, it's called Procedural programming.

Re: Goodbye, Object Oriented Programming

#25

Post by Clubber » Sun, Jul 24, 2016, 8:04 PM UTC

Nullabillity wrote: post #16

Clubber wrote: post #10

Regarding: Class Copier { Scanner scanner; Printer printer; function start() { printer.start(); } } --- Placing a Start() in a PoweredDevice base class doesn't make sense in the real world. There are plenty of "powered devices" that don't have start buttons. A phone, a fish tank pump, a smoke alarm, none have a "start." A powered device should have just that, a PowerOn() and PowerOff() or SetPower(bool isOn). I would…

Indent it with 4 spaces to make HN recognize it as a code block.

Thanks. I felt like Richard in the tab vs. space debate on Silicon Valley.

Re: Goodbye, Object Oriented Programming

#26

Post by ebbv » Sun, Jul 24, 2016, 8:05 PM UTC

millstone wrote: post #21

Let me try to list the objections: 1. Inheritance creates dependencies on their parent class 2. Multiple inheritance is hard 3. Inheritance makes you vulnerable to changes in self-use 4. Hierarchies are awkward for expressing certain relationships All true. But likewise, functions introduce dependencies on their arguments, and data structures introduces dependencies on their fields. You must consider your dependencie…

That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right way and you don't like the right way?"

His entire problem seems to be he thought OO was a magic bullet he could do whatever he wanted with and then he learned there was more to using OO than the three concepts he cites at the beginning.

And this guy has supposedly been writing in OO languages for decades? What?

Re: Goodbye, Object Oriented Programming

#27

Post by Stratoscope » Sun, Jul 24, 2016, 8:05 PM UTC

Nullabillity wrote: post #16

Clubber wrote: post #10

Regarding: Class Copier { Scanner scanner; Printer printer; function start() { printer.start(); } } --- Placing a Start() in a PoweredDevice base class doesn't make sense in the real world. There are plenty of "powered devices" that don't have start buttons. A phone, a fish tank pump, a smoke alarm, none have a "start." A powered device should have just that, a PowerOn() and PowerOff() or SetPower(bool isOn). I would…

Indent it with 4 spaces to make HN recognize it as a code block.

It's two spaces, but of course four works too.

https://news.ycombinator.com/formatdoc

Re: Goodbye, Object Oriented Programming

#28

Post by vinceguidry » Sun, Jul 24, 2016, 8:10 PM UTC

Inheritance is overused in OOP. There are many ways to share object behaviors, inheritance only works well when you expect all objects of both classes to share all behavior except one or two things. Even then, you should investigate dependency injection before reaching for inheritance.

For the example given for the Triangle Problem, the author isn't clear about exactly what behavior is being shared among the classes. The top of the tree, PoweredDevice, gives an indication, but my guess is that there are more responsibilities than just power, these responsibilities aren't being reflected in the domain model as they should be.

Instances of a class share behavior with other instances, it is the state that differs, i.e. the data being stored in the instance variables. In the example hierarchy, the state being stored is left out of the analysis, but it's the first place I would look for a missing domain concept. My guess would be that the most concrete class is going to be models of consumer peripherals, of which instances are intended to represent actual devices.

In this case a copier, which contains both a scanner and a printer, but not an actual discernible model of scanner or printer, would simply inherit from PoweredDevice. That it has this functionality does not mean it need actually have those in its class hierarchy. It is a job better suited for mixins, or injected dependencies.

Re: Goodbye, Object Oriented Programming

#29

Post by ebbv » Sun, Jul 24, 2016, 8:10 PM UTC

Illniyar wrote: post #5

I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…

I agree with you. Moreover, I think anyone who is rabidly attaching themselves to a programming paradigm of any kind is doing themselves (and anyone who has to work with them) a disservice. It's all just tools. Committing yourself fully to a single tool like functional or OO or whatever is just as silly as a woodworker attaching themselves to only a single form of joinery.

Re: Goodbye, Object Oriented Programming

#30

Post by sebastianconcpt » Sun, Jul 24, 2016, 8:11 PM UTC

It seems to me that my OOP is so functional that I didn't felt these issues that bad (it is true that I actively evaded them with the design) and at the same time it sounds like falling into that is typical of not so great OOP programmers.

It's curious to see that OOP hate coming from someone that got a chance to work in Smalltalk.