Live data from Hacker News

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

mail-archive.com

51–60 of 177 posts

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

#51

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…

> It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea

It's not a bad base for UI programming. There is quite a lot of functionality that is suited to the OOP paradigm.

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

#53

Perhaps this would work: Build a program that... * That has a hardcoded list of strings baked into it * Accepts as inputs a filename (but can be empty) and a substring to search for * At runtime, either (a) (if filename empty) iterates over hardcoded list of strings, or (b) opens file and iterates over lines in it * For each string / line, if contains search string then output to stdout (and maybe also increment a co…

Refactoring something along the lines of

    static void Main(string[] args) {
        var filename = args[0];
        var needle = args[1];
        var linesToProcess = filename != '' ? File.ReadAllLines(filename) : HardcodedLines;
        ProcessLines(linesToProcess, needle);        
    }

    static void ProcesLines(string[] linesToProcess, string needle) {
        // lines-processing code...
    }
into something like

    static void Main(string[] args) {
        var filename = args[0];
        var needle = args[1];
        var linesProvider = filename != '' ? FileLinesProvider(filename) : MemoryLinesProvider(HardcodedLines);
        ProcessLines(lineProvider, needle);
    }

    static void ProcesLines(ILinesProvider linesProvider, string needle) {
        var linesToProcess = linesProvider.GetLines();
        // lines-processing code...
    }
would still need some justification, IMO: what's the benefit of giving ILinesProvider to the ProcessLines instead of just string[]?

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

#54
If I had to state a law about how to do OOP correctly it would be:

- A base class and its implementation(s) must never be written by the same person.

Obviously a bit of a strong opinion, but inheritance should delimit layers of abstraction, technically separating the responsibility of developers.

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

#55
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…

I think it's a bad question, just like every single request to "model real world things X,Y,Z for no reason" and the article explains this:

    You can’t add code to ducks.

    You can’t refactor ducks.

    Ducks don’t implement protocols.
If I got asked this question I'd probably spend the whole interview inquiring about the purpose of the modeling. It's for a simulation? What info do you want to get from the simulation? It's for an ERP app?

I don't have problems with simple tasks which are not real-world but abstract something from the real-world use cases. The problem with "model me a car" is that it abstracts nothing.

Also for the most real-life purposes of modeling a car factory you wouldn't even have a "Car" in your object hierarchy.

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

#56

Perhaps this would work: Build a program that... * That has a hardcoded list of strings baked into it * Accepts as inputs a filename (but can be empty) and a substring to search for * At runtime, either (a) (if filename empty) iterates over hardcoded list of strings, or (b) opens file and iterates over lines in it * For each string / line, if contains search string then output to stdout (and maybe also increment a co…

Refactoring something along the lines of static void Main(string[] args) { var filename = args[0]; var needle = args[1]; var linesToProcess = filename != '' ? File.ReadAllLines(filename) : HardcodedLines; ProcessLines(linesToProcess, needle); } static void ProcesLines(string[] linesToProcess, string needle) { // lines-processing code... } into something like static void Main(string[] args) { var filename = args[0]; v…

[deleted]

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

#57

> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus I wish someone had told me this when I first started coding. I wasted so much time building pointless hierarchies based on ontology rather than DRY.

The thing about the natural world is that “Nature does not practice OOP.” Our nice hierarchies of animals reflect our desire to build hierarchies. Those hierarchies are tools that are useful for many purposes, but they weren’t blueprints for constructing life.

I speculate that if we think of our hierarchies as tools, they say at least as much about our own brains and the problems we’re trying to solve as the do about the domain.

Which is fine, tools exist as levers for the mind. But we shouldn’t confuse them with reality. The map is not the terrain.

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

#58

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.…

Good OOP stuff is usually in a standard library or has to do with computer science stuff instead of business applications. Writing OOP style services and repositories and real-world object hierarchies (Prius inherits from Car and implements IVehicle) is where it sucks.

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

#59

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…

It's really not. For example C# has no guiding principles imo. It's just a hodgepodge of any and all popular language features all lumped together. Java was popular at its inception so it stole lots of Java, as new things have become popular they are added (eg. anonymous functions)

As a dev you just use whatever features u like and can safely ignore the majority of them. Its very non-prescriptive unlike some languages where you must do a thing only one way.

Eg. Inheritance is pretty much terrible, I just never use it. Same way I try to not write bad code and instead write good code.

Also sure you need to put functions in classes, but thats fine, classes are just buckets for code. In any language you need to put your functions somewhere eg. in a text file.

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

#60

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.…

The best thing that object orientation popularized is the interface/protocol abstraction. All the modern languages I learned put this front and center: Go's interfaces, Clojure's protocols and multimethods, Rust's traits.

This apparently goes back to part of the inspiration of Smalltalk (dataless programming). It enables you to create an ubiquitous language and radically improves your ability to structure a program in terms of reusable abstractions. It is fundamentally about hiding complexity and specificity on one end and only requiring or assuming what you _need_ to require or assume on the other.

In comparison to this, inheritance feels like a half baked implementation detail that got out of hand. Especially static inheritance hierarchies feel like the antithesis of object orientation. Pinning everything down and turning a codebase into immovable concrete.

Post reply on HN