Hacker News Reader

Comment by joe_the_user | Hacker News Reader

Object oriented programming is good. Not in absolutely every situation, but for most business applications it's better than the alternatives.

The thing about OO is that as far as I can tell, it's natural. Whatever OO is criticized, people point out that the standard OO example is "car" but the typical OO object in practice is "network credentials permissions". So what? The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car.

And further thing is, the fp thing seems to be something like "we don't do objects at all but we do really elaborate Turing complete types, please don't ask us what the difference is, you wouldn't understand. Don't ask us whether types have private data. Especially don't ask if integers have private bits..."

View on HN

The problem mostly caused by people insists use OO in position where is looks not natural nor make sense.

A connection client is suitable to be written as a class. It didn't make sense for outsider to see what the internal connection state is and manipulate it randomly. You want to just call .connect() and happily use methods on it.

But makes a math method be a class with multi constructor parameter just don't make sense, why not just make it a static method or a bare function(If the language supports it) with multi parameter?

And the most worst problem(Though it is not related to this topic). Someone writes pattern from OO language in other language. Even the language itself has the capability to express it directly and gracefully. (personally I think this is why OO haters exists...)

> The problem mostly caused by people insists use OO in position where is looks not natural nor make sense.

You have exactly the same issue with any paradigm. I am seeing it now with functional programming as people go all obsessive into converting everything into it.

And I'd argue than in both cases trying to use a paradigm for literally everything is a good thing, at least in terms of learning and understanding that paradigm.

Is OO good for everything? No. Is FP good for everything? No. And yet, unless you've attempted to use them for everything, you're unlikely to understand why they ain't good for everything.

The problem mostly caused by people insists use OO in position where is looks not natural nor make sense.

Another poster mentioned that any paradigm can be misused. Yes but OO has a sort-of "least bad to miss-use" quality.

You can have a date object or a query object or Haskell-function object, and they are all conceptually terrible but they still allow people who only know OO to work with all kinds of things. OO is created to "glue" anything together with anything else. The equivalent with functional programming is "FP is created to "glue" only other functional elements together with other functional elements".

And OO definitely offends the sensibility of those who things done correctly and well - which includes lots of programmers. The "least bad" is indeed an enemy of the good. But you're not going to get all the world's systems redone correctly as the new paradigm so if you want to end OO, you'd need an alternative that could also least bad in many circumstances.

I think you're falling into a thinking trap. And I think there's probably a name for it but I don't remember it.

The point I will make is that "a car is an object you can do things with" is actually probably not how you think about a car. Personally I think of my car and the "objects" around me as merely tools I can use to achieve goals.

If I need to go to the shop I don't think to myself: I need to go to the car object and call the door_open(DRIVER_SIDE) method and then call the add_driver(self) method and then the door_close(DRIVER_SIDE) method and then the turn_key() method...

When I need to go to the shop I come up with a shopping list (or more likely get my girlfriend to send it to me) and then I think about my destination and how I can get there. I think of using my car to go there.

So simply put, I think the object model has no relation to how we actually think about objects around us.

The object model (At least alan kay's variant) may be a good description of how humans talk to each other, and I think it has its place for sure, but it's also nothing like the object model which gets sold to people these days.

To me "network credentials permissions" sounds like just some data which describes the permissions required to access another piece of data called a network credential. That's how I think about it, I am not sure it's accurate to say that my method of thinking about it is any more or less natural than thinking of "network credentials permissions" as a thing but personally I would say that considering "network credentials permissions" to be a thing seems just outright wrong.

The point I will make is that "a car is an object you can do things with" is actually probably not how you think about a car.

I can't imagine how this isn't exactly me or someone else thinks about a car. I might then think about what I accomplish with a car. And sure, "car" and "bicycle" are "transportation means I can steer" and feed "transport means" and "destination" into an algorithm and arrive a location. Sure, "transport means" is a higher logical level "car" but both of these go into human thought processes.

The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above.

> I can't imagine how this isn't exactly me or someone else thinks about a car.

I think it's more likely that you think this is how you think about the car because you think it makes sense to think about a car that way. In reality if I recall correctly when we have a goal of "going somewhere" we don't see "objects" we see "obstacles and tools which overcome obstacles". Specifically you don't see what a car is (a lump of metal which moves with you inside) but rather you see what a car means (a tool which can be used to overcome the obstacle of distance).

Although honestly I can't come up with what to look for on the net to source this information and I currently don't have time to do it.

> The only reason you don't think you think about that, is because your self-conception apparently delegates the process to your reflexes. But if you have explain to someone how this happens, you reflexively dive and give some English equivalent to your narative above.

Even if that is the case, I don't see how an English explanation can map onto an object model. It more closely approximates a procedural model.

To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method.

> To point directly at the problem: Does the car contain me or am I riding the car? How do you describe this concept using objects? When you think of the car as a tool rather than a thing it becomes obvious: The car is a function which transforms some data <me> by changing the position from one place to another. With this approach I am no longer stuck trying to work out if I the car object has to have a add_driver() method or if I should have an ride_car() method.

Both and as someone who has implemented vehicle logic in a game before you usually want to model both.

You’ve done the classic programmer thing of creating an abstraction over the grisly details with ride_car which is great if you’re just representing the fact abstractly but if not someone still needs to care about the details and model them. An abstract version is great then for example if you're planning but it doesn't remove the need to build the details out.

Damn, you really nailed it with that car example, because I can already see the sort of errors that might arise:

* did not call putFeetInCar before adding driver

* did not call putShoesOnFeet before calling putFeetInCar

* did not call gripKeyInHand or set up HandKeyAllocator

* did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector

* did not do correct incantation of prayer to Cthulu to ensure AxelAlignmentProtocol is properly specified

Man, this really is the crux of it for me: when the focal point is a series of opaque state mutations, there are exponentially more ways to do those steps in the wrong order than the right order. And the contracts for those methods have absolutely zilch to say about what they assume has already happened or will happen after they're called. You just have to know (or hope somebody wrote it down in English). This is my biggest pain point/source of anxiety when working in an OOP codebase.

And then guess what? Suddenly you're extremely concerned with the internal state of those objects. Because understanding it is essential if you want to have any hope of actually using them. And the great irony is that this completely undermines one of the main benefits of OOP: private state that the outside world doesn't have to care about.

> did not call putFeetInCar before adding driver

> did not call putShoesOnFeet before calling putFeetInCar

That's bad architecture, not an OOP flaw. These should've been private methods called and error-handled properly from driver.prepareForDriving, or even implemented as a DriverPreparedForDriving subtype.

> did not set up HandKeyAllocatorManager or use KeyDashboardMeldConnector to insert key into KeyHoleDoodadInterfaceXConnector

All these sound like bad OOP (or Java) to me, a HandKeyAllocatorManager is not a thing in the domain. I'd rather build my logic around objects like HandsContents, KeyKeyholeCompatibility or SeatedDriver.

I’ve decided to assume this is perfect satire and have upvoted it accordingly.

It's not supposed to be, what made you think that?

I think that the way we think about this has more to do with the purpose or intent and maybe with the language that we speak and it becomes more complex when thinking from self perspective.

For me, for example describing a process where one person gives the car to another person to go somewhere it feel very easy to say

  person1.press car_key.button
  car.open_door
  person1.explains person2
  person1.gives car_key to: person2
  person2.enters car
  engine.starts
  car.moves

Of course OO is not satisfying completely this but in general I see that nothing happens without someone/object/matter doing something on something else.

So I except that something happens into/to the world because an object.did something to a subject. Else nothing happens. thus it does not feel natural to think first about an action that requires a force and the subject to be aplied to. Always an object is exercising an energy/force onto something else.

To summarize I think if one is a person who thinks more about energy than matter then fp feels natural. If one is a person who things more about matter then oo is more natural.

We do go to the door and call door_open(DRIVER_SIDE) - it's just second nature now because we've done it so many times that it takes up no conscious bandwidth. But that subroutine is running somewhere in the brain.

To use a car, we're performing a bunch of actions involving modifying the state of a car. That seems to be quite analogous to the OOP way of thinking.

You're right that we don't consciously think of car travel in this way, but I don't see that as inconsistent with OOP either. Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.

> Our thinking about cars is highly abstract, as though it's an abstract class/interface with a single go_somewhere(destination) method, which fits quite well with OOP thinking.

So what you're saying is I'm going to have to downcast to a concrete class to figure out if my object is actually suitable for going to the store or my bathroom (my house isn't big enough to drive a car through).

Lines up with most OOP systems I've worked in.

Ideally the interface is named in a way that's self-documenting and makes it clear that it's not referring to moving around your house, no downcasting required.

But the thing is that now the car has to know about the world. If there's a wall on the driver side how can it open the door?

I'm not dogmatic on OOP vs FP, but let me take the side of FP here, we could model this as the car being a data structure with its position (x, y, etc), and a representation of what opening the door is (width of the car + length of the door, an anonymous function, or a named function, that can be made polymorphic) and now our open_door(car, world) can take both and the world doesn't need to know about what is a car and the car doesn't need to know about the world either, it just serves as a mapping, and the function open_door checks the positions of car in the world, transforms the car according to its procedure and checks it still fits the world and if not it produces an annoying beep.

>The thing about OO is that as far as I can tell, it's natural

How so? If it was natural, it wouldn't take 30 years of programming to arrive to it (and in a bad way).

>The usefulness of OO is exactly that allows, partially, some totally fungly thing like "network credentials permissions" to be treated, sort of, like a thing, we sort of, understand, a fricken car.

Cars have instance variables and methods? You car.drive() your car?

I mean at the right level of abstraction - yes...?

You can represent "network credentials permissions" or "car" naturally in non-OO too though. Non-OO-procedural programmers would probably create a struct representing the credentials and have a bunch of (hopefully namespaced) freestanding functions to operate on it, just like OO has a bunch of methods operating on the class. Functional programmers would similarly represent that as a data structure and a set of functions to operate on it. Furthermore, since the data structures used are usually the core language provided ones, you can use the full collection of the languages library of functions to operate on it to transform, filter or otherwise process the data.

You can do that with OO too, of course, except that encapsulation means you typically do it in the class and if you want to do other transformations, you either need to amend the class, expose the internal data (directly or through getters/setters), or inherit from the class. In a functional or procedural language you can also provide encapsulation/data hiding if you wish.

I don't think either approach is more natural than the other and they're both more or less equivalent, its just that different languages encourage different default approaches.

Personally, after twenty years of programming, I find that I value immutable data over all in most cases (ie unless I'm writing performance-sensitive C++ code) and as long as I have that and a reasonable way of managing it, I don't really mind if I'm representing things as immutable objects or something else.

Reply on news.ycombinator.com