Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

mail-archive.com

Post reply on HN
Print view View original

31–40 of 177 posts

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#31

Post by bowsamic »

fabian2k wrote: post #11
bowsamic wrote: post #7

Earlier quoted context omitted.

Inheritance is just a total mess. Overriding a method, especially a non-abstract one, feels more like monkeypatching. It feels unsafe, it's not clear if I should do it, etc. A lot of Apple APIs mark which methods should be overridden and which shouldn't be. It just generally feels like a crappy approach. Languages with deep inheritance trees like Ruby and Smalltalk and even Objective-C are also extremely difficult to…

The user you responded to uses C#, you can't override arbitrary methods there. Only methods explicity declared as virtual can be overriden, so this is different than many other OO languages. I think this is also the better approach, making inheritance something you have to explicitly design for instead of a way to monkeypatch almost everything.

Wow that's very interesting, and much better

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#32

Post by A321321 »

smcl wrote: post #17
fabian2k wrote: post #11

Earlier quoted context omitted.

The user you responded to uses C#, you can't override arbitrary methods there. Only methods explicity declared as virtual can be overriden, so this is different than many other OO languages. I think this is also the better approach, making inheritance something you have to explicitly design for instead of a way to monkeypatch almost everything.

> Only methods explicity declared as virtual can be overriden You can with "new", no? public class Foo { public void Say() { Console.WriteLine("Foo!"); } public void Think() { Console.WriteLine("I;m thinkin about thos beans"); } public class Bar : Foo { new public void Say() { Console.WriteLine("Actually, Bar!"); } } So with Bar we have inherited Think(), but have overridden Say(). Ok technically the MSDN docs will s…

No, that’s not how new works. Any method in the base class will still call the “hidden” method.

https://dotnetfiddle.net/zcVPof

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#34

Post by ncmncm »

bdg wrote: post #21

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I al…

Yes. This is why "default virtual" is such a dumb idea.

Virtual functions are about implementation: a derived type that overrides a virtual function does so specifically in order to deliver a specialized implementation.

The degree to which your class's virtuals match its public interface is an exact measure of how bad that interface is, as an OO abstraction. If your class was doing enough work to earn its keep, it would be presenting an interface in terms the client wants to see. Those are implemented for variant internal representations by composing calls to one or more private virtual interfaces.

The above is true about OO subsystems. But not all uses of virtual functions are about OO. Virtual functions are a mechanism. Anywhere the mechanism is useful, it is OK to use it, OO or no OO.

Java offers no other organizational facilities than OO mechanisms, so there you have little choice but to use them everywhere. In problems not suited to OO solutions, use of virtual calls may have nothing to do with OO, and none of the OO rules need apply: if it works, it works.

Any language that offers only one kind of abstraction is a very poor and limited language. Calling it "pure" should not fool anybody. The world is complicated and demands many kinds of tools. Any one will only match certain aspects of certain problems.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#35

Post by AutomatedChaos »

Not sure why but this book came to mind: https://en.wikipedia.org/wiki/The_Island_of_Doctor_Moreau

"You can’t fake the ability to turn a duck into a penguin by moving its duckness into an animal of some other species that can be replaced at runtime."

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#36

Post by substation13 »

The OOP community fascinates me.

It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat better (e.g. Java Record types) but perhaps it is time to admit these languages just aren't a good fit?

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#37

Post by smcl »

A321321 wrote: post #32
smcl wrote: post #17

Earlier quoted context omitted.

> Only methods explicity declared as virtual can be overriden You can with "new", no? public class Foo { public void Say() { Console.WriteLine("Foo!"); } public void Think() { Console.WriteLine("I;m thinkin about thos beans"); } public class Bar : Foo { new public void Say() { Console.WriteLine("Actually, Bar!"); } } So with Bar we have inherited Think(), but have overridden Say(). Ok technically the MSDN docs will s…

No, that’s not how new works. Any method in the base class will still call the “hidden” method. https://dotnetfiddle.net/zcVPof

Ah yeah you're right :)

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#38

Post by mynameisash »

DeathArrow wrote: post #20

After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…

I'm reminded of the "Object oriented programming is bad" series: https://youtu.be/QM1iUe6IofM

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#39

Post by qsort »

DeathArrow wrote: post #20

After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…

For all its blemishes it's still the most natural way to represent the concept of "user-defined data type" in a procedural language.

"Modeling the world as OOP", OTOH, is a load of bull.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#40

Post by fabian2k »

substation13 wrote: post #36

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat bette…

The only real difference is that inheritance as explicit language support while composition is something you can easily implement with common language features. It's not really more difficult to use composition than inheritance.

As an example, if I want to use composition in C# using ASP.NET, I simply inject the class I want to use into my new class using the built-in DI. This is as simple as extending the class.

Post reply on HN