Anthropomorphism Gone Wrong: OOP • Hacker News Board

Re: Anthropomorphism Gone Wrong: OOP

#21

Post by k__ » Sat, Jan 03, 2015, 5:26 PM UTC

mc808 wrote: post #17

Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up looking like old-fashioned procedural code coated with a sugary OOP shell. Encapsulation and inheritance and stateful objects have their place, but the "object" metaphor can really lead down the wrong path when taken too literally (as it is in practically every co…

If I don't explicitly need "state" (user-data in models or GUI-state in view-models) I leave it out.

Most of the time I use classes and their objects as a stateless bag of related methods. Like namespaces...

Re: Anthropomorphism Gone Wrong: OOP

#22

Post by platz » Sat, Jan 03, 2015, 5:32 PM UTC

adwn wrote: post #16

olavk wrote: post #12

It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most oft…

You hit the nail on the head. Objects in OO shouldn't be a projection of the problem domain, they're a way to structure the program (there's some overlap, of course). Many people seem to get this wrong, probably in part due to introductory examples doing it wrong.

I suppose you disagree with Eric Evans method of Domain Driven Design (DDD - http://domainlanguage.com/)

Don't people who practice DDD, including Martin Fowler, commonly talk about the benefits of some of it's concepts, while modeling the Domain using Aggregrate Roots, Bounded Contexts, etc?

Re: Anthropomorphism Gone Wrong: OOP

#23

Post by [deleted] » Sat, Jan 03, 2015, 5:36 PM UTC

murbard2 wrote: post #4

Regarding Dijkstra's quote: our brains are wired to model people with internal desires... sometimes it can lead to some errors, like animism, but if used correctly, it can be a powerful technique. I've designed concurrent systems with many processes talking to each other. Each process has a name that describes a profession, owns certain parts of a shared database and transacts with other processes. Sure that analogy…

[deleted]

Re: Anthropomorphism Gone Wrong: OOP

#24

Post by alkonaut » Sat, Jan 03, 2015, 5:41 PM UTC

ronbo wrote: post #10

still i would like to see a concrete example where OOP is better. I thought that OOP had advantages in larger projects with many kinds of data where it helped organize the code to make it more readable and editable. At that point you need to be careful how you use it to make it manageable. Not sure how small an example would could be before it started to show some benefits.

The encapsulation that guarantees invariants is the greatest benefit. This can be Done in another way by immutable structures and Functional programming. This way is in many ways better than OO but both are vastly superior to having publicly mutable structures modified by procedures.

Semantic organization where methods are defined near the data (the recepie is on the flour package) is a benefit for sure, but it's just a preference.

Re: Anthropomorphism Gone Wrong: OOP

#25

Post by asveikau » Sat, Jan 03, 2015, 5:42 PM UTC

Using the article's example, maybe if you break the abstraction of the iterator, you realize that moving students to classrooms might just be a single pointer assignment, which can be done in a few instructions. In other words, maybe the classes blind you to the fact that the students don't need to be iterated.

I feel like this is one of my bigger gripes with OOP code bases: overemphasis on abstraction sometimes makes simple and efficient solutions harder to come by.

Re: Anthropomorphism Gone Wrong: OOP

#26

Post by huherto » Sat, Jan 03, 2015, 5:45 PM UTC

olavk wrote: post #12

It is really hard to decide on the best way to model, since it doesn't resemble any real-world programming problem. But OO culture has an unfortunate tradition of using bad examples by using physical objects as analogies for objects in code. Cars, fruits, students, teachers, whatever. Problem is, objects in code rarely correspond to physical objects. In the cases where physical objects are represented, it is most oft…

Those examples are used for teaching because they are interesting for novices. In a real project, you use your objects that are useful for organizing your code. Modules, layers, gateways to external systems, etc.

Re: Anthropomorphism Gone Wrong: OOP

#27

Post by [deleted] » Sat, Jan 03, 2015, 5:52 PM UTC

basaah wrote: post #20

mrcwinn wrote: post #7

I was disappointed by this article in the end. I was ready for a good old fashioned OOP bash, supported by strong opinions and examples. We should always remain open to new (or old, in this case!) patterns. Instead we get a "tie" given a very simple (not real world) example. In the end I'm left with the same conclusion. Given that there is no obvious performance gain from a procedural approach, I would opt for a desi…

I was also disappointed by the atricle's end: Pretty much only the Dijksta quote was worth reading. The title promised to backup the claim with a real-world experience of OOP, but alas, it did not deliver such. OOP is better where you code more readably(in comparison with procedural) and where it makes you enjoy coding more. The conditions for when it does that differ from persons to person and from project to projec…

[deleted]

Re: Anthropomorphism Gone Wrong: OOP

#28

Post by zak_mc_kracken » Sat, Jan 03, 2015, 5:54 PM UTC

mc808 wrote: post #17

Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up looking like old-fashioned procedural code coated with a sugary OOP shell. Encapsulation and inheritance and stateful objects have their place, but the "object" metaphor can really lead down the wrong path when taken too literally (as it is in practically every co…

> Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers,

These are not mutually exclusive.

Re: Anthropomorphism Gone Wrong: OOP

#29

Post by haberman » Sat, Jan 03, 2015, 5:59 PM UTC

mc808 wrote: post #17

Like many people I went through an "objectify all the things!" phase, but now I find myself moving more and more to stateless service layers, which ends up looking like old-fashioned procedural code coated with a sugary OOP shell. Encapsulation and inheritance and stateful objects have their place, but the "object" metaphor can really lead down the wrong path when taken too literally (as it is in practically every co…

Could not agree more.

I've heard of interviewers who say to candidates: "I have a bookshelf. Design me an OO interface." They want the candidate to create objects for Shelf, Book, etc. without knowing anything at all about what the software system is supposed to do! This is so backwards IMO that I cringe just to tell this story.

Re: Anthropomorphism Gone Wrong: OOP

#30

Post by imsofuture » Sat, Jan 03, 2015, 6:14 PM UTC

Completely disagree with the Dijkstra quote. Mentally modelling command flow as a 'person' makes total sense, as long as you keep in mind the abilities/limitations of the 'person' you're talking about.

That said, I agree that OOP is anthropomorphism gone crazy.